[Issue 4595] [tdpl] Accessing non-static member of a null reference compiles

[d-bugmail at puremagic.com]

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



--- Comment #14 from Kenji Hara <k.hara.pg at gmail.com> 2013-09-19 00:33:55 PDT ---
(In reply to comment #13)
> After a few years of D use, I actually find the above will create problems. We
> often use traits like these to check whether something is compilable, even if
> the object is left uninitialized. 

Today, code flow analysis for class ctor call (super(...) and this(...))
behaves as follows.

class Foo
{
    this(int) {}
}

class Bar : Foo
{
    this()
    {
        static assert(is(typeof(super(0))));
        static if (is(typeof(super(0)))) {}
        // inside typeof(), code flow analysis never works.

        super(1);
        // OK

        static assert(is(typeof(super(0))));
        static if (is(typeof(super(0)))) {}
        // also OK

        super(2);
        // Error: multiple constructor call
    }
    this(int)
    {
        static assert( __traits(compiles, super(1)));
        // inside __traits(compiles), code flow analysis is enabled.

        super(1);
        // Error: multiple constructor call

        static assert(!__traits(compiles, super(2)));
        // The _second_ super call makes error.

        super(3);
        // Error: multiple constructor call
    }
}

This is expected behavior, from my compiler-internal knowledge.

- `is(typeof(exp))` tests that the exp has valid type or not. For type
calculation, the code flow analysis and its validation result is just
unnecessary.

- `__traits(compiles, exp)` tests the exact validness of `exp` at there. In
other words, `__traits(compiles)` converts the error occurrence on the `exp`
semantic analysis to the compile-time boolean value. In there, code flow
analysis is enabled, and the errors will be counted normally.

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