D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 6784 - (D1 only) Compile-time constant assigned with a runtime value
Summary: (D1 only) Compile-time constant assigned with a runtime value
Status: RESOLVED WORKSFORME
Alias: None
Product: D
Classification: Unclassified
Component: dmd (show other issues)
Version: D1 (retired)
Hardware: All All
: P2 normal
Assignee: Don
URL:
Keywords: accepts-invalid
Depends on:
Blocks:
 
Reported: 2011-10-07 15:37 UTC by bearophile_hugs
Modified: 2019-11-07 08:10 UTC (History)
3 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description bearophile_hugs 2011-10-07 15:37:34 UTC 
This program compiles with no errors (DMD 2.056head), but I think it's wrong because the compile-time constant y gets assigned with a runtime value:


struct Foo {
    immutable uint x;
    void foo() {
        enum uint y = x;
    }
}
void main(string[] args) {
    auto f = Foo(args.length);
}
Comment 1 yebblies 2012-01-31 18:09:43 UTC 
Related to Issue 2414.

What differs here is that
enum uint y = x

Is translated to 
enum uint y = this.x

And DotIdExp::optimize does not turn this into a constant value, and there is no error when it fails when called with result & WANTinterpret.

Unfortunately adding an error causes problems with other code, presumably because DotIdExp::optimize is use from other places like CallExp::optimize that expect it to just try and finish without errors.

Reassigning to Don as he fixed 2414 and understands the constfolding/interpreter code a lot better than I do.

Probably applies to D1/const variables too.
Comment 2 Don 2012-02-22 01:14:30 UTC 
The error message should only happen when result & WANTinterpret.

But, the problem is, as usual, those %&/$# AAs. The builtin AA properties aren't converted into function calls.
Rather than add another hack for this, it's probably better to wait for bug 5590 to be pulled in.
Comment 3 Don 2012-02-22 11:59:55 UTC 
FWIW, this patch in optimize.c, DotVarExp::optimize() fixes the bug. But, the exclusion of TOKassocarrayliteral is just a hack.


    if (e && e->op == TOKstructliteral)
    {   StructLiteralExp *sle = (StructLiteralExp *)e;
        VarDeclaration *vf = var->isVarDeclaration();
        if (vf)
        {
            Expression *e = sle->getField(type, vf->offset);
            if (e && e != EXP_CANT_INTERPRET)
                return e;
        }
    }
+   else if (result & WANTinterpret && (!e || e->op != TOKassocarrayliteral))
+        error("%s cannot be evaluated at compile time", e1->toChars());
 
    return this;
}
Comment 4 hsteoh 2014-11-06 01:33:19 UTC 
Tested on git HEAD, now the compiler correctly issues an error:

------
test.d(4): Error: value of 'this' is not known at compile time
------

The test code was modified to use size_t instead of uint, since on 64-bit platforms args.length is ulong, and the compiler will complain that you can't assign ulong to uint. But that's irrelevant to this bug.
Comment 5 yebblies 2014-11-06 01:38:21 UTC 
Does it still exist in D1?
Comment 6 hsteoh 2014-11-06 01:59:27 UTC 
No idea, should the bug be reopened for D1-only?
Comment 7 yebblies 2014-12-12 05:31:10 UTC 
Might as well reopen until someone can confirm it's fixed for D1.
Comment 8 RazvanN 2019-11-07 08:10:13 UTC 
D1 is no longer supported. Closing as WORKSFORME.