digitalmars.D.bugs - [Issue 6169] New: [CTFE] pure functions cannot compute constants using functions not marked as pure
- d-bugmail puremagic.com (27/27) Jun 16 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6169
- d-bugmail puremagic.com (53/53) Jun 16 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6169
- d-bugmail puremagic.com (12/12) Jun 17 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6169
- d-bugmail puremagic.com (27/36) Jun 17 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6169
- d-bugmail puremagic.com (13/13) Jan 28 2012 http://d.puremagic.com/issues/show_bug.cgi?id=6169
- d-bugmail puremagic.com (6/6) Apr 27 2012 http://d.puremagic.com/issues/show_bug.cgi?id=6169
- d-bugmail puremagic.com (26/26) Jan 31 2013 http://d.puremagic.com/issues/show_bug.cgi?id=6169
- d-bugmail puremagic.com (7/7) Jan 31 2013 http://d.puremagic.com/issues/show_bug.cgi?id=6169
- d-bugmail puremagic.com (10/10) Feb 16 2013 http://d.puremagic.com/issues/show_bug.cgi?id=6169
- d-bugmail puremagic.com (17/17) May 04 2013 http://d.puremagic.com/issues/show_bug.cgi?id=6169
- d-bugmail puremagic.com (21/37) May 04 2013 http://d.puremagic.com/issues/show_bug.cgi?id=6169
- d-bugmail puremagic.com (9/30) May 11 2013 http://d.puremagic.com/issues/show_bug.cgi?id=6169
- d-bugmail puremagic.com (11/11) Jun 30 2013 http://d.puremagic.com/issues/show_bug.cgi?id=6169
- d-bugmail puremagic.com (10/10) Jun 30 2013 http://d.puremagic.com/issues/show_bug.cgi?id=6169
- d-bugmail puremagic.com (35/35) Jul 01 2013 http://d.puremagic.com/issues/show_bug.cgi?id=6169
- d-bugmail puremagic.com (7/10) Jul 01 2013 http://d.puremagic.com/issues/show_bug.cgi?id=6169
- d-bugmail puremagic.com (12/12) Jul 07 2013 http://d.puremagic.com/issues/show_bug.cgi?id=6169
- d-bugmail puremagic.com (9/9) Jul 13 2013 http://d.puremagic.com/issues/show_bug.cgi?id=6169
http://d.puremagic.com/issues/show_bug.cgi?id=6169
Summary: [CTFE] pure functions cannot compute constants using
functions not marked as pure
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nobody puremagic.com
ReportedBy: timon.gehr gmx.ch
With DMD 2.053:
string impure(){return ";";}
void main() pure{
enum s = impure(); // fail (cannot call impure function 'impure')
mixin(impure()); // ditto
}
Removing the pure attribute from 'main' or adding it to 'impure' makes the code
pass.
This restriction is nonsensical and should be removed.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 16 2011
d-bugmail puremagic.com
http://d.puremagic.com/issues/show_bug.cgi?id=6169
bearophile_hugs eml.cc changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bearophile_hugs eml.cc
I think you have just made D a bit more complex :-)
In D compile time and run time are fully separated (and computing an enum
inside a CTFE function spans a fully separated and fully enclosed
sub-computation), so there is no way compile-time constants can break the
purity of a pure function. So this looks OK regarding run-time purity.
Currently in D in a function the path of compile-time execution has to be pure,
even if the whole function is not pure, so you are right saying this program
has to compile:
int x = 10;
int foo(bool b) {
if (b)
x++;
return 0;
}
pure void main() {
enum y = foo(false);
}
If in future D compilers CTFE will be allowed to modify global variables too,
then I think your idea is in troubles. Otherwise at first sight it seems OK,
but more thinking is required because future D compilers are allowed to perform
pure-related optimizations on pure functions even in CTFE. Is nonpurity able to
cause troubles to pure functions at compile-time?
In this program spam is pure, and it calls bar, that's not pure, to compute z.
But this program doesn't cause troubles even if a smart D compiler applies pure
optimization of spam()+spam() replacing it with spam()*2 because z is computed
only once, because bar() is called in a sub-computation that's fully sealed:
pure nothrow int foo() {
int x = 1;
nothrow int bar(int y) { // nonpure
x++;
return x + y;
}
pure nothrow int spam() {
enum z = bar(1); // calls a nonpure
return z;
}
return spam() + spam();
}
enum r = foo();
void main() {}
So if I am right, then this proposal is safe :-)
One problem left is that this proposal introduces another special case in D,
because the rules of purity have to say a pure function is allowed to call an
impure one at compile-time. Is it worth it? I think it's acceptable.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 16 2011
http://d.puremagic.com/issues/show_bug.cgi?id=6169
Don <clugdbug yahoo.com.au> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |clugdbug yahoo.com.au
Applies to safe as well.
CTFE enforces safety and purity, using more relaxed rules than safe and pure
do.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 17 2011
http://d.puremagic.com/issues/show_bug.cgi?id=6169
Interestingly, it does not apply to nothrow unless interpreting the function
fails :). I think this is a diagnostics bug:
int foo(){return 0;}
int bar(){assert(0);}
void main() nothrow{
enum f = foo(); // fine
enum b = bar(); // assert(0) failed / bar is not nothrow
// main is nothrow yet may throw
}
...
If in future D compilers CTFE will be allowed to modify global variables too,
then I think your idea is in troubles.
[snip.]
I think letting CTFE mutate static storage is a bad idea anyways, but actually
that does not matter for this. You are just computing some manifest constant
during compile time that is later used to influence the function's behavior.
This cannot possibly make the function return different results when passed the
same arguments (even during compile time), ergo it is still pure.
...
One problem left is that this proposal introduces another special case in D,
because the rules of purity have to say a pure function is allowed to call an
impure one at compile-time. Is it worth it? I think it's acceptable.
[snip.]
Actually I think this is the same 'special case' as the one that says manifest
constants are evaluated during compile time. The behavior we have now is a
special case of this 'special case'. I think we remove some special casing (and
therefore complexity) by fixing this.
Oh, and this should work too:
string impure(){return ";";}
void main() pure{static s = impure();}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 17 2011
http://d.puremagic.com/issues/show_bug.cgi?id=6169
yebblies <yebblies gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |patch
CC| |yebblies gmail.com
AssignedTo|nobody puremagic.com |yebblies gmail.com
https://github.com/D-Programming-Language/dmd/pull/652
Please test and review if you're interested.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 28 2012
http://d.puremagic.com/issues/show_bug.cgi?id=6169 *** Issue 7994 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Apr 27 2012
http://d.puremagic.com/issues/show_bug.cgi?id=6169
monarchdodra gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |monarchdodra gmail.com
Just wanted to add that I just hit this bug. Any news on the progression of
this bug fix?
I'm hitting this on a rather trivial use case, where I'm just trying to
generate a compile-time-known error message:
//----
import std.string : format;
struct S
{
int* p;
ref inout(int) get() inout nothrow pure safe
{
enum message = format("Called %s on null %s.", "get", S.stringof);
assert(p, message);
return *p;
}
}
//----
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 31 2013
http://d.puremagic.com/issues/show_bug.cgi?id=6169 This bug is exactly where it has been for the last year - awaiting approval from Walter. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 31 2013
http://d.puremagic.com/issues/show_bug.cgi?id=6169
yebblies <yebblies gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hsteoh quickfur.ath.cx
*** Issue 9517 has been marked as a duplicate of this issue. ***
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 16 2013
http://d.puremagic.com/issues/show_bug.cgi?id=6169 Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/42d1af1635fec1c43bbda6c4a3894e148ca6fc22 Fix Issue 6169 - [CTFE] pure functions cannot compute constants using functions not marked as pure When running semantic on an expression used anywhere that forces compile time evaluation, use a scope flag to prevent purity and safety checks on function calls. This allows better purity/safety inferrence as well. https://github.com/D-Programming-Language/dmd/commit/15a57832d0a9ed18eb619c58261db6c2eedc663e Issue 6169 - [CTFE] pure functions cannot compute constants using functions not marked as pure -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 04 2013
http://d.puremagic.com/issues/show_bug.cgi?id=6169
pure nothrow int foo() {
int x = 1;
nothrow int bar(int y) { // nonpure
x++;
return x + y;
}
pure nothrow int spam() {
enum z = bar(1); // calls a nonpure
return z;
}
return spam() + spam();
}
enum r = foo();
void main() {}
A reduction of that code:
int foo() {
int x = 0;
int bar() {
return x;
}
enum y = bar();
return 0;
}
enum r = foo();
void main() {}
It gives:
temp.d(4): Error: variable x cannot be read at compile time
temp.d(6): called from here: bar()
temp.d(9): called from here: foo()
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 04 2013
http://d.puremagic.com/issues/show_bug.cgi?id=6169
A reduction of that code:
int foo() {
int x = 0;
int bar() {
return x;
}
enum y = bar();
return 0;
}
enum r = foo();
void main() {}
It gives:
temp.d(4): Error: variable x cannot be read at compile time
temp.d(6): called from here: bar()
temp.d(9): called from here: foo()
That appears to be correct. While both 'foo' and 'bar' are running at compile
time, they are in different compile time evaluation contexts. The evaluation
of 'y' _must_ be independent of the running of 'foo'.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 11 2013
http://d.puremagic.com/issues/show_bug.cgi?id=6169
yebblies <yebblies gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
This was fixed ages ago.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 30 2013
http://d.puremagic.com/issues/show_bug.cgi?id=6169
yebblies <yebblies gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |andrej.mitrovich gmail.com
*** Issue 10506 has been marked as a duplicate of this issue. ***
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 30 2013
http://d.puremagic.com/issues/show_bug.cgi?id=6169
monarchdodra gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
Not fully fixed for safe. The conditions to reproduce are a bit complicated
actually. It requires attribute inference, mixin and default args (!) I'm not
sure which it is that it producing the problem:
--------
string bar(string op = "+") property
{
return "a" ~ op ~ "b";
}
void foo()()
{
int a, b;
int c = mixin(bar);
}
safe void main()
{
foo!()();
}
--------
main.d(14): Error: safe function 'D main' cannot call system function
'main.foo!().foo'
--------
Observations:
1) The problem is only with safe, not pure.
2) Calling "min(bar("+"))" also makes the problem go away.
Built with HEAD from 30-06-2013
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 01 2013
http://d.puremagic.com/issues/show_bug.cgi?id=6169 ---Not fully fixed for safe. The conditions to reproduce are a bit complicated actually. It requires attribute inference, mixin and default args (!) I'm not sure which it is that it producing the problem:https://github.com/D-Programming-Language/dmd/pull/2290 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 01 2013
http://d.puremagic.com/issues/show_bug.cgi?id=6169 Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/c2647ba31e7a60ccc354e67aad3a05ceaf7b755e Remain fix for issue 6169 Add ctfeResolveProperties() which avoids purity and safety check https://github.com/D-Programming-Language/dmd/commit/d895e4e8463de991c7b3ea723803374d6f9bf36a Remain fix for issue 6169 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 07 2013
http://d.puremagic.com/issues/show_bug.cgi?id=6169
yebblies <yebblies gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |FIXED
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 13 2013