Error: null dereference in function _Dmain

[Jonathan M Davis]

On Monday, July 02, 2012 19:36:21 Namespace wrote:
> > You didn't actually list what error you're seeing. The error
> > that I'm seeing
> > (which may differ from yours' because I'm on the latest master,
> > not 2.059, and
> > you're probably on 2.059) is
> > 
> > q.d(87): Error: constructor q.NotNull!(Foo).NotNull.this is not
> > callable
> > because it is annotated with @disable
> > 
> > And that error is being hit, because you're specifically trying
> > to instatiate
> > your NotNull!Foo with a null literal, and you disabled the
> > constructor which
> > would take typeof(null). The compiler isn't detecting any null
> > references at
> > all. It's complaining about your attempted use of a disabled
> > constructor.
> > 
> > - Jonathan M Davis
> 
> This code: http://dpaste.dzfl.pl/a0939681
> prints
> 
> dmd -w -wi -O -property -unittest -debug -of"not_null"
> "not_null.d" (im Verzeichnis: D:\D\D_Scripts\Test3)
> not_null.d(106): Error: null dereference in function _Dmain
> not_null.d(103): Error: null dereference in function _Dmain
> Kompilierung fehlgeschlagen.
> 
> And even without
> 
> @disable
> this(typeof(null));
> 
> I get the same errors.

Well, I'm getting

q.d(111): Error: no identifier for declarator t
q.d(111): Error: found 'in' when expecting ';'

due to your erroneous use of in a foreach loop instead of ;, but with that 
fixed I see

Error: null dereference in function _Dmain
q.d(103): Error: null dereference in function _Dmain

which refers to

test_not_null_foo(f1);

which is a very weird error. test_not_null_foo takes a NotNull!Foo, not a Foo, 
and f1 is a Foo, and you haven't defined an implicit conversion from Foo to 
NotNull!Foo, so it should give an error about NotNull!Foo not being Foo. If 
you compile without -O, this code compiles without error, which is wrong. And 
if you compile with -O, you get the weird null dereference error. So, I think 
that there are two bugs here, both of them related to alias this, and one of 
them related to -O. Both should be reported ( http://d.puremagic.com/issues ), 
though ideally the code would be reduced to a minimal test case before doing 
so.

By the way, you're handling classes incorrectly in your NotNull struct. 
isPointer!T is false for classes, so your Ptr function is returning a pointer 
to a class rather than a class. You need is(T == class) if you want to test 
whether T is a class. You seem to have created isObject to try and solve that 
problem, but isObject is going to give you funny results if T isn't a class 
but does have an alias this which converts to one.

However, if you fix it so that Ptr returns an inout(T) for classes like it 
should, dmd seems to hit 100% CPU and grow in memory until the OS kills it. 
So, you're definitely hitting a bug with alias this here, but I don't know if 
that's a third bug or something else. I recall there being a recent bug report 
about the compiler running out of memory in a similar situation, but I'd have 
to go digging for it to be sure.

By the way, it's pointless to compile with both -w and -wi. -wi makes it so 
that warnings are displayed without stopping compilation. -w makes it so that 
warnings are displayed and treated as errors (so they stop compilation). Pick 
one or the other. I don't know which the compiler picks if you give it both, 
but it's going to have to pick one or the other, and it may not pick the one 
that you want.

- Jonathan M Davis