fix Issue 23651 - Order dependency in semantic analysis of template members

[WalterBright]

AliasDeclarations should behave like other declarations w.r.t. being able to be lazily semantically evaluated.

[dlang-bot]

Thanks for your pull request, @WalterBright!

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	23651	normal	Order dependency in semantic analysis of template members

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#14843"

[ibuclaw]

At what point should we just put resolving in a visitor or similar encapsulated interface so it isn't just a little special case here, a little bit there, all over the place?

Not that it would solve anything, but might least make it easier to grok what's going on, and allow resolve/match symbols consistently without semantic getting in the way. (Write a spec, follow the spec).

Half of this just looks like treating the visible mould, but actually it's taken over the entire wall.

[WalterBright]

@ibuclaw I actually agree with you. Before I did this PR, I spent a couple frustrating days trying more fundamental solutions, but they'd all fail with weird problems. I'm not happy with this solution, but it has the positive characteristic of working.

resolve/match symbols consistently without semantic getting in the way

Yeah, well, static if gets in the way of that.

[WalterBright]

mixin too.

[ibuclaw]

mixin too.

Mixins yes, though I wonder if there could be a construct for a function/type/variable inside any form of conditional declaration, where if the condition it depends upon results as true, use it, otherwise pass the next matched symbol in scope/import. Would mean doing a light form of semantic on all possible code paths though before we decide keep or discard. I'm probably being too optimistic.

[ibuclaw]

Not great, as now there's yet another "avoid semantic on..." block.