refactor(parse): enable compiling with Libc++ in C++23+

[JohelEGP]

This works around possibly llvm/llvm-project#58206,
as pointed out at #462 (comment).
So now we can compile cppfront with Libc++ in C++23+.

[hsutter]

Thanks! I'm not sure these are actual order dependency bugs in parse.h, but anyway it does seems like there's always another order dependency (or three) to be found in parse.h and I'm looking forward to converting that file in particular to Cpp2... 😏

[JohelEGP]

and I'm looking forward to converting that file in particular to Cpp2...

I'm also looking forward to it!
Specially when you start using @union instead of std::variant.
That might have some interesting effects in compile-times and more.

[JohelEGP]

I'm not sure these are actual order dependency bugs in parse.h

Seems like they are in C++23.
https://www.reddit.com/r/cpp/comments/18ls1ml/comment/ke080ew/?utm_source=share&utm_medium=web2x&context=3 links to issues for https://github.com/microsoft/STL and https://github.com/llvm/llvm-project.
They further link to related issues.
In the LLVM one, Richard Smith replies

The unique_ptr destructor becomes constexpr in C++23, so gets instantiated more eagerly -- at the point of first reference rather than at end of TU. unique_ptr destruction doesn't support incomplete types.

[hsutter]

I tried with GCC 13 in C++23 mode but wasn't able to find such a problem.

It did give one error though, which no other compiler reported and I can't see if there's really a problem... the error is:

In file included from sema.h:21,
                 from to_cpp1.h:21,
                 from cppfront.cpp:18:
reflect.h2: In instantiation of ‘bool cpp2::meta::apply_metafunctions(cpp2::declaration_node&, type_declaration&, const auto:162&) [with auto:162 = cpp2::parser::apply_type_metafunctions(cpp2::declaration_node&)::<lambda(const std::string&)>]’:
sema.h:35:31:   required from here
reflect.h2:1372:9: error: possibly dangling reference to a temporary [-Werror=dangling-reference]
 1372 |         for meta*.template_arguments()
      |         ^~~
reflect.h2:1373:61: note: the temporary was destroyed at the end of the full expression ‘<lambda closure object>cpp2::meta::apply_metafunctions<cpp2::parser::apply_type_metafunctions(cpp2::declaration_node&)::<lambda(const std::string&)> >(cpp2::declaration_node&, type_declaration&, const cpp2::parser::apply_type_metafunctions(cpp2::declaration_node&)::<lambda(const std::string&)>&)::<lambda(Obj&&, Params&& ...)>().cpp2::meta::apply_metafunctions<cpp2::parser::apply_type_metafunctions(cpp2::declaration_node&)::<lambda(const std::string&)> >(cpp2::declaration_node&, type_declaration&, const cpp2::parser::apply_type_metafunctions(cpp2::declaration_node&)::<lambda(const std::string&)>&)::<lambda(Obj&&, Params&& ...)>((* &(& cpp2::assert_not_null<const std::unique_ptr<id_expression_node>&>((* & meta)))->std::unique_ptr<cpp2::id_expression_node>::operator*()))’
 1373 |         do  (arg)

The reflect.h2 code is:

        for meta*.template_arguments()
        do  (arg)
            args.push_back( arg.to_string() );

which is lowered to this:

        for ( 
             auto const& arg : CPP2_UFCS(template_arguments)((*cpp2::assert_not_null(meta))) ) 
            CPP2_UFCS(push_back)(args, CPP2_UFCS(to_string)(arg));

You last took a pass at the UFCS macros... do you see any actual possible dangling that could be happening?

[JohelEGP]

I reduced the lambda to just

[&]<typename Obj> [[nodiscard]] (Obj && obj)
                    ->decltype(auto)  {
              return std::forward<decltype(obj)>(obj).template_arguments();
          }((*cpp2::assert_not_null(meta)))

It looks fine.
This must be one of these:

• https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111607
• https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109640

[JohelEGP]

The effect of -Werror on the warning can be disabled with -Wno-error=dangling-reference.

[hsutter]

Done in 9585ecc

[JohelEGP]

This most closely matches your error: https://stackoverflow.com/questions/77101074/possible-false-positive-from-wdangling-reference-using-g.
For it they opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111410#c0.
Looks like only GCC 13 accepts -Wno-error=dangling-reference: https://cpp1.godbolt.org/z/qYEcea77E.
All Unix CI jobs are failing due to that.

[hsutter]

Thanks, I just noticed that too and pushed 9aefcee

Update: Yes, that seems to have fixed it.