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 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.
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









d-bugmail puremagic.com 