http://d.puremagic.com/issues/show_bug.cgi?id=9514

           Summary: "template instance … is not an alias"
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: regression
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: code@klickverbot.at


--- Comment #0 from David Nadlinger <code@klickverbot.at> 2013-02-14 19:41:01 PST ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9514


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com


--- Comment #1 from Walter Bright <bugzilla@digitalmars.com> 2013-02-14 22:39:30 PST ---
If you remove the ": find" it does work.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9514



--- Comment #2 from Kenji Hara <k.hara.pg@gmail.com> 2013-02-15 08:53:11 PST ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9514



--- Comment #3 from David Nadlinger <code@klickverbot.at> 2013-02-15 12:14:19 PST ---
(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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9514



--- Comment #4 from Walter Bright <bugzilla@digitalmars.com> 2013-02-15 14:21:01 PST ---
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;
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9514



--- Comment #5 from Walter Bright <bugzilla@digitalmars.com> 2013-02-15 15:09:19 PST ---
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;
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9514



--- Comment #6 from Kenji Hara <k.hara.pg@gmail.com> 2013-02-15 20:52:35 PST ---
(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...

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9514


Kenji Hara <k.hara.pg@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull, rejects-valid


--- Comment #7 from Kenji Hara <k.hara.pg@gmail.com> 2013-02-16 06:04:43 PST ---
(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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9514



--- Comment #8 from github-bugzilla@puremagic.com 2013-02-16 12:11:07 PST ---
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"

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9514



--- Comment #9 from Walter Bright <bugzilla@digitalmars.com> 2013-02-16 12:17:26 PST ---
The bulk of the reduction was done by dustmite, an amazing tool.

The rest was done by hand.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------