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

[Don]

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.


>
>> I do not understand why it still part of the compiler after we
>> agreed to roll back to the D1 version.
>
> I'm late to the game; how was the D1 version implemented?

It was just extern(C) library functions.

The D2 version is exactly the same thing (all of the D1 functions still 
exist in D2), except that it has an AssociativeArray!(Key, Value) 
wrapper around the extern(C) functions.
Which sounds like a trivial intermediate step to a full library 
implementation, but it isn't.
- it's a template, so it needs to be instantiated. What happens if it 
hasn't been instantiated yet?
- what happens when AssociativeArray isn't a struct template?
- what happens if there's an error while instantiating it?
- what happens when all the functions are inlined away, and you're left 
with just void* pointers?
- what happens when you something of type V[K] interacting with 
something of type AssociativeArray!(K, V)? This happens in things like 
template constraints, is() expressions, etc.
- how is CTFE supposed to deal with this ruddy thing, that's fully of 
nasty casts to void *, and which may yet create AA literals themselves?
- how are you supposed to get sensible error messages out of this beast?

The answer to these questions is, hundreds of hours work, and the 
biggest implementation disaster in D's history. There can be no 
'intermediate step'. The syntax sugar should be added last, not first.