[BUG] g++ 14 `-Wnonnull` triggered when compiling with `-O2`

[Dylam De La Torre]

Describe the bug
Title. This is a pretty weird one, I am not sure why it only happens when compiling with optimizations.

To Reproduce
Steps to reproduce the behavior:

1. Compile with: /usr/bin/g++ -std=c++20 -Wall -Wextra -pedantic -Werror -O2 -I./include/ -o cppfront.exe source/cppfront.cpp
2. Output:

In file included from source/to_cpp1.h:21,
                 from source/cppfront.cpp:18:
source/sema.h: In member function ‘bool cpp2::sema::check(const cpp2::parameter_declaration_node&)’:
source/sema.h:1485:68: error: ‘this’ pointer is null [-Werror=nonnull]
 1485 |             type_name = n.declaration->get_object_type()->to_string();
      |                         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~
In file included from reflect.h2:18,
                 from source/sema.h:21:
source/parse.h:1299:10: note: in a call to non-static member function ‘std::string cpp2::type_id_node::to_string() const’
 1299 |     auto to_string() const
      |          ^~~~~~~~~
cc1plus: all warnings being treated as errors

Additional context
It could be a false-positive, but I haven't analyzed the code yet.

[Herb Sutter]

Thanks! Fixed, or at least "silenced." As I mentioned in the commit: The warning is silenced by adding an assert(not-null). That assertion doesn't get triggered by any of the regression tests, but GCC could be reporting a real latent issue, and if so now with the assert we'll get a nice trackable ICE if we ever do encounter a source file that triggers a problem.

[Dylam De La Torre]

Perfect! By the way, feel free to ignore these newer issues if there are older more important ones, I am reporting what I encounter as I write regular-ish code, there's still a few more I need to open, but they aren't super high priority.

[Herb Sutter]

feel free to ignore these newer issues

Thanks, understood, but in practice when I can't keep up (which has been a lot of the past year) I tend to at least try to stay abreast of the more current ones. And if I can knock out small ones like this one I can reduce the remaining pile by some amount, and most ICEs are easy to resolve (which I can usually just repro in the debugger to find a stray bad dereference or one of the simpler assertion failure) and helps stability. So I do try to do that kind of report a little more responsively. Again, thanks.