[BUG] error when handle types defined with lambda

[steve02081504]

Describe the bug
Doxygen doesn't seem to be able to handle types defined with lambda correctly.
e.g.

template<size_t size>
using unsigned_specific_size_t=decltype(lambda{
	#define TYPE_MAPPER(type) if constexpr(size == sizeof(type))return (type)0;else
	#line 1 "https://github.com/ELC-lang/ELC/tree/master/parts/header_file/files/elc/../../../_share/basic_environment/arithmetic_mapper/unsigned_mapper.hpp"
//unsigned_mapper.hpp
TYPE_MAPPER(uint8_t)
TYPE_MAPPER(uint16_t)
TYPE_MAPPER(uint32_t)
TYPE_MAPPER(uint64_t)
#if defined(ELC_BASE_ENV_HAS_INT128)
TYPE_MAPPER(uint128_t)
#endif
TYPE_MAPPER(::std::uintmax_t)
TYPE_MAPPER(size_t)
TYPE_MAPPER(unsigned char)
TYPE_MAPPER(char8_t)
TYPE_MAPPER(char16_t)
TYPE_MAPPER(char32_t)
TYPE_MAPPER(wchar_t)
TYPE_MAPPER(unsigned short)
TYPE_MAPPER(unsigned int)
TYPE_MAPPER(unsigned long)
TYPE_MAPPER(unsigned long long)

//file_end

	#line 105 "https://github.com/ELC-lang/ELC/tree/master/parts/header_file/files/elc/../../../_share/basic_environment/_body.hpp"
	#undef TYPE_MAPPER
	{}
}());

Expected behavior
Handle it correctly.

Screenshots
https://elc-lang.github.io/ELC/namespaceelc_1_1defs_1_1basic__environment.html#a526ab5592597e881c00a5d308b568bd0

To Reproduce
docs.zip

Version
Doxygen version used: 1.9.8
github action with mattnotmitt/doxygen-action@452281f

Stack trace
none.

Additional context
none.

[albert-github]

The example in the attachment (docs.zip) is a bit large and the problem there is hard to pinpoint, though the small example in the issue already shows the problem of the fact tat the using / decltype /lambda is not handled properly. The problem is even more notably when changing:

#define TYPE_MAPPER(type) if constexpr(size == sizeof(type))return (type)0;else

into

#define TYPE_MAPPER(type) if (constexpr(size == sizeof(type)))return (type)0;else

(the problem is independent of using clang)

[steve02081504]

#10313 (comment)

@albert-github
Thanks for the additions, I think I might have to add a little more stuff here
In the example code snippet provided, lambda is a macro that embellishes the c++23 code rather than a keyword, and you can get it like this (sorry this was an oversight on my part!)

#define lambda []

https://en.cppreference.com/w/cpp/language/lambda

Another thing is that I think if constexpr(...) is a syntactically similar keyword to if(...), whereas if (constexpr(...)) is likely to get an error in the compiler, which may be something to watch out for.
https://en.cppreference.com/w/cpp/language/if

[doxygen]

@steve02081504 Please verify if the latest commit fixes the issue for you. Do not close the issue, this will be done automatically when the next release is made available.

[albert-github]

@doxygen Output looks better though:

When taking the small example in the issue (and MACRO_EXPANSION=NO): example.tar.gz
I get:

and

• strange that in the brief description the TYPE_MAPPER lines are not mentioned and only the brackets, though this is easily explained as SKIP_FUNCTION_MACROS=YES is set by default, so a bit understandable.
• the "initialization" is a multi line initialization and should probably be handled as such, now it is squashed into 1 line.

When setting MACRO_EXPANSION=YES and SKIP_FUNCTION_MACROS=NO we get for the detailed part:

[steve02081504]

@doxygen Thanks for your help, it looks good now!
I've been modifying my project while you've been improving doxygen. I've reverted a workaround for msvc as it was fixed, and unfortunately this new modification has led to another strange output from doxygen. (Personally I think this might count as part of this issue considering it also involves lambda?)
The new problematic code looks like this:

//warp for not_unreadable_istream to make it unreadable
template<class stream_T> requires not_unreadable_istream_class<stream_T>
struct unreadable_wrap:stream_T,instance_struct<unreadable_wrap<stream_T>>,virtual decltype(lambda{
	if constexpr(noexcept_stream_class<stream_T>) {
		if constexpr(data_stream_class<stream_T>)
			return type_info<noexcept_data_istream_t>;
		else
			return type_info<noexcept_text_istream_t<typename stream_T::char_type>>;
	}
	else {
		if constexpr(data_stream_class<stream_T>)
			return type_info<data_istream_t>;
		else
			return type_info<text_istream_t<typename stream_T::char_type>>;
	}
}())::type{
	//coool stuffs!
};

Screenshot of the generated output:

New reproducible code:
docs.zip
The path to the problematic output:
output/structelc_1_1defs_1_1stream__n_1_1unreadable__wrap.html#a958334cb0bfb618ab93c797a08cebedf

[doxygen]

I found a small example to reproduce the problem:

#include <cstdio>
struct B { void f() { printf("B()\n"); } };
struct C { void f() { printf("C()\n"); } };
struct A : decltype([]{
      if constexpr(sizeof(void*)==8) return B();
      else                           return C();
     }())
{
};
int main()
{
  A a;
  a.f();
}

Note that this use of lamdas seems to be a C++20 feature. Also note that doxygen will not be able to evaluate the correct inheritance relation in such cases, but at least it should be able to parse over the decltype stuff.

[doxygen]

@steve02081504 Please verify if the latest commit fixes the problem (with the limitations mentioned).

[albert-github]

@doxygen though less important, but what is the status of the output issue mentioned in #10313 (comment)

[steve02081504]

@steve02081504 Please verify if the latest commit fixes the problem (with the limitations mentioned).

It's working fine thank you for your help! (and apologies for my late testing)
I can't wait to see the next version of doxygenXD
By the way, could you please take a look at #9621 sometime? I'm not sure my wishes were made clear and understood in that issue but it looks like it's been stuck there for a while.

[doxygen]

@doxygen though less important, but what is the status of the output issue mentioned in #10313 (comment)

I think the "multi-line initializer for using" can indeed better be handled as in other places. Can you make a new issue for this specifically?

[albert-github]

The requested (#10313 (comment)) issue: "Multi line initialization for using" #10334

[doxygen]

This issue was previously marked 'fixed but not released',
which means it should be fixed in doxygen version 1.10.0.
Please verify if this is indeed the case. Reopen the
issue if you think it is not fixed and please include any additional information
that you think can be relevant (preferably in the form of a self-contained example).