fix issue 15069 - nonsense struct template instantiations still compile

[ghost]

No description provided.

[dlang-bot]

Thanks for your pull request and interest in making D better, @StianGulpen! 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
✓	15069	regression	[REG2.064] nonsense struct template instantiations still compile

Testing this PR locally

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

dub fetch digger
dub run digger -- build "stable + dmd#10613"

[ghost]

Sorry I had modified the original test case. The problem is still there.

[ghost]

I've found the real problem this time. An alias is created for each template parameter and this way the compiler thinks that it can be the enclosing template.

[ghost]

ping for merge, this is good now. BTW there's also #10571.

[Geod24]

This doesn't look like a good solution to be fair. Sure it works, but having a boolean just to signal that this alias is not exactly like other aliases just means the abstraction was either wrong or incomplete to begin with.

The fact that template parameters are aliases in the scope has been problematic from time to time. For example, most of the complexity in the C++ mangling code on POSIX comes from that.

It's too minor to be worth a revert, but wanted to point it out in case you want to explore this further @StianGulpen .

[ghost]

I think about a refactoring in master after the next patch release. Instead of the field, new classes (or at least one, derived from AliasParameter) would be added. The information carried by the field would be available by the type of the class(es) (e.g isTemplateParameterAlias()). This new classes could be use to work on the other problems you mentioned earlier and that I was not aware of.

The idea is

class TemplateParameterAlias : AliasDeclaration {}

Honestly, knowing how things are generally well decomposed in DMDFE I was surprised that not utility exists allowing to make the difference, before my fix.

[ghost]

well TemplateParameterAlias is maybe too near from AliasTemplateParameter but you got the idea I think.

[Geod24]

This new classes could be use to work on the other problems you mentioned earlier and that I was not aware of.

I originally tried to solve the problem at the root when I encountered it, using a similar approach, but aliases are removed as early as possible, so adding a new class won't help, and refactoring the code to prevent aliases being eliminated is a daunting task. And if you manage to get the job done, you're going to have to convince the reviewers that your hundreds of lines of refactoring are adding value.

Another trivial example:

void main () { bar(42); }
alias Foo = Object;
void bar (immutable(char)[] arg) {}
void bar (Foo arg) {}

This outputs:

hack.d(1): Error: none of the overloads of bar are callable using argument types (int), candidates are:
hack.d(3):        hack.bar(string arg)
hack.d(4):        hack.bar(Object arg)

As you can see, the alias is bypassed and the suggestion uses Object as parameter, not Foo. But funnily, it shows string while I typed in immutable(char)[] ! That's because there is a special handling somewhere in DMD to work around this problem of aliases being too transparent.

[ghost]

Your example is not related to template params being pulled in the scope as aliases. It rather illustrates a problem of a special case with unexpected side effects. Special cases are evils.

[Geod24]

Your example is not related to template params being pulled in the scope as aliases.

Correct, but it is another symptom of the early elimination of aliases.

Special cases are evils.

👍
IMO this is a perfect example of how they just shift the problem elsewhere.

[ghost]

Ok we agree finally.