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

           Summary: Regression (2.064 git-head): Cannot interpret struct
                    at compile-time
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: regression
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: andrej.mitrovich@gmail.com


--- Comment #0 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-07-27 12:51:13 PDT ---
-----
struct Struct
{
    int x;
}

template GetSomething(S...)
{
    alias GetSomething = int;
}

void main()
{
    alias X = GetSomething!(Struct.tupleof[0]);
}
-----

> Error: Cannot interpret Struct at compile time

-- 
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=10722



--- Comment #1 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-07-27 13:10:20 PDT ---
Introduced by e1ce57e - Merge pull request #2136 from donc/future_of_ctfe

https://github.com/D-Programming-Language/dmd/pull/2136

-- 
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=10722


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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull


--- Comment #2 from Kenji Hara <k.hara.pg@gmail.com> 2013-08-15 03:10:06 PDT ---
https://github.com/D-Programming-Language/dmd/pull/2477

-- 
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=10722



--- Comment #3 from github-bugzilla@puremagic.com 2013-08-15 23:20:28 PDT ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/a8d1df98864cd27d14da2ac7477ed53a9ec223f5
fix Issue 10722 - Regression (2.064 git-head): Cannot interpret struct at
compile-time

https://github.com/D-Programming-Language/dmd/commit/aa8b1b8797f0faa26637bddd4cf30940ec43b471 Merge pull request #2477 from 9rnsr/fix10722

[REG2.064a] Issue 10722 - Cannot interpret struct at compile-time

-- 
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=10722


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla@digitalmars.com
         Resolution|                            |FIXED


-- 
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=10722


Jacob Carlborg <doob@me.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |doob@me.com


--- Comment #4 from Jacob Carlborg <doob@me.com> 2013-09-12 12:37:34 PDT ---
(In reply to comment #3)
> Commits pushed to master at https://github.com/D-Programming-Language/dmd
> 
> https://github.com/D-Programming-Language/dmd/commit/a8d1df98864cd27d14da2ac7477ed53a9ec223f5
> fix Issue 10722 - Regression (2.064 git-head): Cannot interpret struct at
> compile-time
> 
> https://github.com/D-Programming-Language/dmd/commit/aa8b1b8797f0faa26637bddd4cf30940ec43b471 Merge pull request #2477 from 9rnsr/fix10722
> 
> [REG2.064a] Issue 10722 - Cannot interpret struct at compile-time

This fix has changed the behavior of .stringof. Before the fix:

struct Foo
{
    int a;
}

static assert(Foo.tupleof[0].stringof == "(Foo).a");

After the fix:

static assert(Foo.tupleof[0].stringof == "a");

This has broken my library Orange, which is being integrated as std.serialization.

-- 
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=10722



--- Comment #5 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-09-12 14:31:35 PDT ---
(In reply to comment #4)
> This has broken my library Orange, which is being integrated as std.serialization.

Using .stringof is very unreliable (precisely because of these sort of changes, and since .stringof isn't really properly defined).

I suggest using __traits(identifier, Foo.tupleof[0]) instead.

-- 
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=10722



--- Comment #6 from Kenji Hara <k.hara.pg@gmail.com> 2013-09-12 18:31:45 PDT ---
(In reply to comment #5)
> (In reply to comment #4)
> > This has broken my library Orange, which is being integrated as std.serialization.
> 
> Using .stringof is very unreliable (precisely because of these sort of changes, and since .stringof isn't really properly defined).
> 
> I suggest using __traits(identifier, Foo.tupleof[0]) instead.

Today stringof property merely prints the internal AST which its semantic
analysis has been done.
And of course internal AST format does not have any backward compatibility
beyond compiler releases.

(Note that compiler cannot determine the stringof property result before semantic analysis, because the property could be overridden by user-defined field.)

So the result format is not defined at all.

-- 
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=10722



--- Comment #7 from Jacob Carlborg <doob@me.com> 2013-09-12 23:59:44 PDT ---
(In reply to comment #5)

> Using .stringof is very unreliable (precisely because of these sort of changes, and since .stringof isn't really properly defined).
> 
> I suggest using __traits(identifier, Foo.tupleof[0]) instead.

I suspected that, that was why I didn't create a new bug report.

-- 
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=10722



--- Comment #8 from Jacob Carlborg <doob@me.com> 2013-09-13 00:02:16 PDT ---
(In reply to comment #6)

> Today stringof property merely prints the internal AST which its semantic
> analysis has been done.
> And of course internal AST format does not have any backward compatibility
> beyond compiler releases.
> 
> (Note that compiler cannot determine the stringof property result before semantic analysis, because the property could be overridden by user-defined field.)
> 
> So the result format is not defined at all.

I understand that, but it has stayed the same of the last 6-7 years. This should be clearly stated in the documentation. Or it should be defined.

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