CTFE bug causes null check to pass on null pointers (Issue 7602)

[Jens Mueller]

Don wrote:
> On 19.03.2012 18:25, H. S. Teoh wrote:
> >On Mon, Mar 19, 2012 at 09:49:07AM +0100, Don Clugston wrote:
> >[...]
> >>Yes. The existing D2 AA implementation is hopelessly broken.
> >>You have to understand that the whole implementation of AAs in D2 is
> >>a HACK. It is extremely complicated and the slightest change to any
> >>code in the compiler or the runtime can break it. Basically CTFE has
> >>to reverse-engineer the druntime code in order to make it to work.
> >>It's not an implementation issue, it's a fundamental design flaw.
> >
> >I'm working on my AA implementation, hopefully to get it to the point it
> >can replace the current mess. It already fixes a number of AA-related
> >issues in the bug tracker.
> >
> >The main idea is to require a minimal number of lowerings from the
> >compiler (effectively nothing more than syntactic sugar such as V[K] and
> >AA literal syntax), and everything else will be done via existing
> >operator overloading and templating mechanisms. Ideally, CTFE will "just
> >work" with this implementation instead of requiring druntime-specific
> >hacks in the compiler (but I'm not sure whether this will work, since it
> >has to do memory allocations -- does CTFE support that?).
> 
> Yes, CTFE supports 'new'. The big issue for the runtime is
> supporting AA literals. CTFE needs to be able to take the output of
> the runtime functions, and pass it as an AA literal to the rest of
> the compiler.

Interesting. How do I make use of this?

struct Foo {}

Foo* foo()
{
    auto a = new Foo;
    return a;
}

unittest
{
	//enum b = foo(); // fails
}

=> Error: cannot use non-constant CTFE pointer in an initializer

What's the trick to use memory allocated in a CTFE. Say e.g. I want to
build a tree at compile time using CTFE.

Jens