Bug 9514 – "template instance … is not an alias"

Unfortunately I don't have a reduced test case yet, but DMD from the latest staging branch (6207580a) contains at least one regression that affects Thrift. To reproduce, run: git clone git://git.apache.org/thrift.git cd thrift/lib/d/src dmd -c -unittest thrift/internal/codegen.d It will fail with --- thrift/internal/codegen.d(125): Error: template instance find!("a.name == b") find is not a template declaration, it is a alias --- and a slew of follow-up error messages. Note the "import std.algorithm : find" a few lines before; the issue might be related to selective import handling.

If you remove the ": find" it does work.

This problem had occured by this commit: Revision: de4f8f6bf8dc9fcc1730ea4d7f2bbd3e74880f08 Message: Merge pull request #1543 from 9rnsr/fix5933 Issue 5933 & 7159 & 9377 - Invoke function semantic3 correctly where it is required. ---- Fix-up way for thrift code is: In thrift/libe/d/src/thrift/codegen/base.d version (unittest) { // Cannot make this nested in the unittest block due to a »no size yet for // forward reference« error. struct Foo { //----> Move Foo into unittest with changing to `static struct` string a; int b; int c; mixin TStructHelpers!([ TFieldMeta("a", 1), TFieldMeta("b", 2, TReq.OPT_IN_REQ_OUT), TFieldMeta("c", 3, TReq.REQUIRED, "4") ]); } } ---- I think this is not a compiler issue. Before the compiler change, a member template function call had not run its semantic3 in some case. It was wrong for auto return type inference and attribute inference feature, but at the same time it had accidentally deferred some forward reference error. In past std.numeric module has such a hidden forward reference bug, and I had fixed it for compiler. Even worse thing, fixing such a bug is sometimes much difficult. If a template member function is tested inside template constraint, the actual error messages will be gagged. Note: workaround pull for std.numeric module. https://github.com/D-Programming-Language/phobos/pull/1096 Let's back to the Thrift code issue. This is just my prediction, the Foo declaration contains "mixin TStructHelpers!(...)", and it may have some forward reference error as like explained above. David Nadlinger, You have control.

(In reply to comment #2) > Let's back to the Thrift code issue. This is just my prediction, the Foo > declaration contains "mixin TStructHelpers!(...)", and it may have some forward > reference error as like explained above. Okay, the issue seems to be connected to the fact that the code contains an import cycle between thrift.internal.codegen and thrift.codegen.base (that I probably introduced by accident while refactoring). You say that you think that this is not a compiler issue. Could you elaborate a bit? Moving the struct inside the unittest block hides the problem because the struct is no longer semantic'd. But I'm not sure what part of the code would be illegal in the first place? I can certainly work around the issue in the Thrift tests (although it's a bit cumbersome, as I don't have commit access). The thing I'm worried about is pushing out a release with a known regression/change in behavior that leads to a completely nonsensical error message and might also occur in other code.

So far, I've reduced it to: ------------------------------ import std.typetuple : TypeTuple; template TStructHelpers() { alias typeof(this) This; bool opEquals(This ) { thriftOpEqualsImpl; } bool thriftOpEqualsImpl() { foreach (name; FieldNames!This) return ; } } struct Foo { mixin TStructHelpers!(); } template memberReq(T, string name, alias fieldMetaData = cast()null) { enum memberReq = memberReqImpl!(T, name, fieldMetaData); } import std.algorithm : find; template memberReqImpl(T, string name, alias fieldMetaData) { enum meta = find!`a.name == b`; } template notIgnored(T, string name= null) { enum notIgnored = memberReq!(T, name) ; } template FieldNames(T, alias fieldMetaData = cast()null) { StaticFilter!( All!( PApply!(), PApply!(notIgnored, T) )) FieldNames; } template StaticFilter(alias pred) { static if (pred!()) TypeTuple!() StaticFilter; } template PApply() { alias void PApply; } template PApply(alias Target, T...) { template PApply() { Target!(PApplyMergeArgs!(ConfinedTuple!T).Result) PApply; } } template PApplyMergeArgs(alias Preset) { alias TypeTuple!(Preset.Tuple) Result; } template Instantiate(alias Template, Params...) { Template!Params Instantiate; } template All(T...) { template All() { Instantiate!(T[1 .. $])All; } } template ConfinedTuple(T...) { alias T Tuple; }

A smaller case: ---------------- template TStructHelpers() { void opEquals(Foo) { FieldNames!(); } } struct Foo { mixin TStructHelpers!(); } import std.algorithm : find; template FieldNames() { static if (find!`true`) int FieldNames; }

(In reply to comment #4) (In reply to comment #5) > A smaller case: > ---------------- > template TStructHelpers() { > > void opEquals(Foo) { > FieldNames!(); > } > } > > > struct Foo { > mixin TStructHelpers!(); > } > > import std.algorithm : find; > > template FieldNames() { > static if (find!`true`) int FieldNames; > } Hmm, maybe the root cause is the combination of selective import and unresolved forward reference. Looks like "Merge pull request #1543" was a trigger for put it in the table. Technically, current "selective/renamed import" makes anonymous import declaration and alias declaration. They have no internal relation, so forward reference resolution is done separately. BUT, it should be together. Yet I don't know well about the import mechanism. I need a bit more time to fix it...

(In reply to comment #6) > Hmm, maybe the root cause is the combination of selective import and unresolved > forward reference. Looks like "Merge pull request #1543" was a trigger for put > it in the table. OK, I finally agree that this is an actual compiler regression. https://github.com/D-Programming-Language/dmd/pull/1665 Walter, thank you for your case reduction work.

Commit pushed to staging at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/0efbffdaab79b7b099e780716aebf92a6054e26e Merge pull request #1665 from 9rnsr/fix9514 Issue 9514 - "template instance … is not an alias"

The bulk of the reduction was done by dustmite, an amazing tool. The rest was done by hand.

Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/4040d2578026554719eb983ba487726188b18908 fix Issue 9514 - "template instance … is not an alias" https://github.com/D-Programming-Language/dmd/commit/03b0cad6bdfe9646f0907ca3abb8d1ac65073192 Merge pull request #1665 from 9rnsr/fix9514 Issue 9514 - "template instance … is not an alias"

*** Issue 8907 has been marked as a duplicate of this issue. ***

Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/53f165ea15c8317d8a331214d5be3d22d9aacbfc Move issue 9514 test case to compilable/testfwdref.d

Commit pushed to stable at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/53f165ea15c8317d8a331214d5be3d22d9aacbfc Move issue 9514 test case to compilable/testfwdref.d