Fix incorrect tag generation for enum classes

[duckdoom5]

Currently invalid source is generated for scoped enums (enum class).

This patch will resolve this issue by adding class when it is a scoped enum.

I've also added an early out to skip printing the tag is the class isn't incomplete, since that shouldn't be necessary in those cases. (Though maybe we should add this as an option so you'd still be able to force print it. Eg. new method PrintTagIfNeeded?)

[tritao]

Looks good, but its failing CI: https://github.com/mono/CppSharp/actions/runs/13123101712/job/36613458471?pr=1900#step:10:210

[duckdoom5]

Hm, interesting.. I guess it's not enough to know if it's incomplete or not. Might look into it a bit tomorrow or just remove the early out for now

[duckdoom5]

@tritao
Okay, so I've been looking into this and it seems relatively easy to fix. I just need to check if there is an ambiguous name within the current namespace. So, I've added that function.

I'm just running into an issue:

Can you tell me why the stdlib.h functions are not included in the ASTContext?

[tritao]

@tritao Okay, so I've been looking into this and it seems relatively easy to fix. I just need to check if there is an ambiguous name within the current namespace. So, I've added that function.

I'm just running into an issue:

Can you tell me why the stdlib.h functions are not included in the ASTContext?

I think it's because of this: https://github.com/mono/CppSharp/blob/main/src/CppParser/Parser.cpp#L1025

e965803

Basically it's almost rarely needed for binding purposes and makes a difference when it comes to performance.

I am guessing it's causing issues in this new approach for this PR?

[duckdoom5]

Ah yeah, that makes total sense.
I'll convert that into an option and default it to skip like it is now. That should resolve this issue

[duckdoom5]

@tritao So ran into a couple of issues again which I resolved today. I'll make more PR's for those in a bit.

Last issue I'm dealing with now, is that if I enable parsing of the system headers, the generated Std-Symbols.cpp file adds the following invalid declaration:
template __declspec(dllexport) std::char_traits<char>& std::char_traits<char>::operator=(std::char_traits<char>&&);

1 error generated.
\CppSharp\build\gen\Common\Std-symbols.cpp(7,80): error: explicit instantiation refers to member function 'std::char_traits::operator=' that is not an instantiation
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.42.34433\include__msvc_string_view.hpp(465,8): note: explicit instantiation refers here

Any ideas? (I should also note that it now adds way more declarations then before)

[tritao]

Kinda hard to say why, but if it's getting generated then presumably CppSharp think it's needed when it shouldn't, so maybe we should just ignore such std::char_traits from consideration. If more stuff is getting generated, then I guess we need to be way more agressive in general in pruning system things from being generated.

It could be we're missing some check in those passes to skip system headers.

[duckdoom5]

Hm, yeah I noticed some other things as well, but I'll leave that discussion for later. Want to get this fixed first and maybe then ask some questions about how some things are designed currently cus I'm a little confused about translations units atm.