digitalmars.D.bugs - [Issue 4001] New: ctfe return value is handled incorrectly when used as template argument
- d-bugmail puremagic.com (44/44) Mar 24 2010 http://d.puremagic.com/issues/show_bug.cgi?id=4001
- d-bugmail puremagic.com (23/23) Mar 24 2010 http://d.puremagic.com/issues/show_bug.cgi?id=4001
- d-bugmail puremagic.com (14/16) Mar 24 2010 http://d.puremagic.com/issues/show_bug.cgi?id=4001
- d-bugmail puremagic.com (15/24) Mar 24 2010 http://d.puremagic.com/issues/show_bug.cgi?id=4001
- d-bugmail puremagic.com (13/13) Apr 26 2011 http://d.puremagic.com/issues/show_bug.cgi?id=4001
- d-bugmail puremagic.com (13/13) Apr 27 2011 http://d.puremagic.com/issues/show_bug.cgi?id=4001
http://d.puremagic.com/issues/show_bug.cgi?id=4001 Summary: ctfe return value is handled incorrectly when used as template argument Product: D Version: 2.041 Platform: x86 OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nobody puremagic.com ReportedBy: jelszonak gmail.com PDT --- Note that the dmd version I was working with was 2.042, but it was still unavailable in the version list. The reduced test case is the following: import std.metastrings; // dummy ctfe-capable function needed to reproduce the error long parseLong(string timeStr) { return 42; } // ctfe-capable function to demonstrate that a value is calculated in compile-time string longToStr(long val) { if (val < 10) { return "" ~ cast(char)(val + '0'); } else { return longToStr(val / 10) ~ longToStr(val % 10); } } void main(string[] args) { const long mylong = parseLong("mystring"); pragma(msg, "fine ", longToStr(mylong) ); // compiles and prints pragma(msg, "bug? ", std.metastrings.toStringNow!(mylong) ); // error } For this code, the compiler output is fine 42 bug? c:\Program Files\.....\src\phobos\std\metastrings.d(97): Error: expression mylong < 0L is not constant or does not evaluate to a bool I think this is a bug, toStringNow should work just as like longToStr. I checked its source code, but found no reason for the compile error, it seems to do the same thing with templates as longToStr with ctfe. The bug was confirmed on the newsgroups, see thread starting with http://digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=107973 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 24 2010
http://d.puremagic.com/issues/show_bug.cgi?id=4001 Don <clugdbug yahoo.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |clugdbug yahoo.com.au This isn't actually a CTFE problem. The issue is that constant folding isn't being performed on const variables with initializers. BTW in the original bug, you can replace 'const' with 'enum' and it will work fine. Note that const variables are NOT evaluated at compile time. But in these kind of situations, it should do the same thing it does with a CTFE function call. Reduced test case: ---- int space() { return 4001; } void oddity4001() { const int bowie = space(); static assert(space() == 4001); // OK static assert(bowie == 4001); // doesn't compile } -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 24 2010
http://d.puremagic.com/issues/show_bug.cgi?id=4001 Steven Schveighoffer <schveiguy yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |schveiguy yahoo.com 11:29:52 PDT --- < Note that constvariables are NOT evaluated at compile time. But in these kind of situations, it should do the same thing it does with a CTFE function call.Then how does the first pragma work? It uses the same const variable that supposedly isn't evaluatable at compile time in the second pragma... -Steve -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 24 2010
http://d.puremagic.com/issues/show_bug.cgi?id=4001< Note that constI didn't express that very clearly. Const variables are not evaluated at instantiation. It is permitted for a const variable to be determined at runtime. If a CTFE function call is made, all the arguments are interpreted before calling the function. In the test case, it only becomes a compile-time value while evaluating the pragma. (The pragma is forcing it to be a compile-time value). The bug is that this constant folding is not happening in template instantiations, static assert, static if, etc. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------variables are NOT evaluated at compile time. But in these kind of situations, it should do the same thing it does with a CTFE function call.Then how does the first pragma work? It uses the same const variable that supposedly isn't evaluatable at compile time in the second pragma... -Steve
Mar 24 2010
http://d.puremagic.com/issues/show_bug.cgi?id=4001 Don <clugdbug yahoo.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|ctfe return value is |const variables should be |handled incorrectly when |readable inside CTFE |used as template argument | Original title: ctfe return value is handled incorrectly when used as template argument -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Apr 26 2011
http://d.puremagic.com/issues/show_bug.cgi?id=4001 Walter Bright <bugzilla digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |bugzilla digitalmars.com Resolution| |FIXED 20:07:11 PDT --- https://github.com/D-Programming-Language/dmd/commit/97c73b140f1cde5d0b713eb72fd1e82084a6ac11 https://github.com/D-Programming-Language/dmd/commit/13dcf90d934325b4f37c50679e07978a821c4249 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Apr 27 2011