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


Don <clugd...@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch
                 CC|                            |clugd...@yahoo.com.au
           Platform|Other                       |All
            Summary|can't fully use floats      |can't fully use
                   |computed in CTFE as         |compile-time floats as
                   |template parameters         |template parameters
         OS/Version|Linux                       |All




--- Comment #5 from Don <clugd...@yahoo.com.au>  2009-07-13 00:09:29 PDT ---
Reduced test case shows it doesn't require CTFE:
-----
enum float one = 1 * 1;
template X(float E) { int X = 2; }
alias X!(one * one) X3;
----

This is really complicated, and took me ages to track down.
First problem is in declaration.c, near the end of VarDeclaration::semantic().
It calculates the value of the manifest constant, but discards the result
unless
it was an int or a string! That's a waste, since it was successfully
calculated.

 In optimize.c expandVar() copys the exprInitializer and semantically analyzes
it, but it doesn't change the exprInitializer. So ei->type remains null the
next time expandVar is called for that same variable.
And since expandVar sets v->scope to NULL, it never gets another chance to
evaluate it.
So in optimize.c line 92, it bypasses the call to e = ei->copy(), returning
NULL from the function.
--> it cannot be evaluated at compile time.

The final patch is tiny: add floating point variables to the list of values
which get saved.

// line 1150 declaration.c || e->op==TOKfloat64


            e = e->optimize(WANTvalue | WANTinterpret);
            else
            e = e->optimize(WANTvalue);
-            if (e->op == TOKint64 || e->op == TOKstring)
+            if (e->op == TOKint64 || e->op == TOKstring || e->op==TOKfloat64)
            {
            ei->exp = e;        // no errors, keep result
            }

However, I think the logic in expandVar() is probably also wrong.
The bug can also be fixed by adding this line in optimize.c, line 89:

            e = e->semantic(v->scope);
            e = e->implicitCastTo(v->scope, v->type);
+            ei->type = e->type;
            v->scope = NULL;

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

Reply via email to