www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 10722] New: Regression (2.064 git-head): Cannot interpret struct at compile-time

reply d-bugmail puremagic.com writes:
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



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: -------
Jul 27 2013
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10722




13:10:20 PDT ---


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: -------
Jul 27 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10722


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

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



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: -------
Aug 15 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10722




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


[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: -------
Aug 15 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Aug 15 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10722


Jacob Carlborg <doob me.com> changed:

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




 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

 
 [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: -------
Sep 12 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10722




14:31:35 PDT ---

 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: -------
Sep 12 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10722






 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: -------
Sep 12 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10722






 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: -------
Sep 12 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10722






 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: -------
Sep 13 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10722




06:49:43 PDT ---
.stringof representation has changed in many parts of the compiler, I guess
this current usage of it had the biggest effect yet. I suggest we add a note in
the documentation to avoid using .stringof for code-generation, and prefer
things like __traits(identifier), or one of the Phobos helper functions such as
"fullyQualifiedName".

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