Fix 21785 - Improve error messages for opaque enums

[MoonlightSentinel]

The error messages for default initialized variables of opaque enums were horrid and contained misleading informations.
This PR removes them by by checking whether semantic was already run in case of an enum without members.

Some examples:

enum NoBase;
enum WithBase : long;

// Not handled yet
struct S;
enum OpaqueBase : S;

void main()
{
    NoBase nb;
    WithBase wb;
    OpaqueBase ob;
}

[Geod24]

Well we don't know the enum definition, so assuming the initializer is its base .init is wrong. The enum could start at 1 for example, or long.min.

[MoonlightSentinel]

Well we don't know the enum definition, so assuming the initializer is its base .init is wrong. The enum could start at 1 for example, or long.min.

Aren't opaque enums more intended as a strong typedef (e.g. __c_long).

But i guess I'll adapt this PR to create a proper error message.

[ibuclaw]

Aren't opaque enums more intended as a strong typedef (e.g. __c_long).

But i guess I'll adapt this PR to create a proper error message.

Nope, they are just hidden/forward reference types, typically you pass them around by pointer, same as opaque structs.

C long and friends are just a special case.

[MoonlightSentinel]

This snippet doesn't involve a forward reference and therefore compiles now.

[MoonlightSentinel]

This line isn't covered because actual forward references crash dmd...

Will open another PR for those errors.

[dlang-bot]

Thanks for your pull request and interest in making D better, @MoonlightSentinel! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	21785	normal	Cannot declare variable of opaque enum with base type

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#12325"

[Geod24]

LGTM. Just a question: What does the error looks like with e.g. enum NoBase; Nobase nb = void; ?

[MoonlightSentinel]

There is no error because NoBase defaults to int (spec 17.1.3) and void initialization is allowed when the base type is not opaque.
Added two examples to the test,