Error: null dereference in function _Dmain

[Jonathan M Davis]

On Monday, July 02, 2012 20:52:19 Namespace wrote:
> > 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 ;,
> 
> Sorry, that comes of my little compiler hack, as you can see here:
> http://forum.dlang.org/thread/rbltrlxsogrfxjzqfpxe@forum.dlang.org?page=3
> and here, if you like to read my mother language ;)
> http://blog.rswhite.de/archives/791

If you want to play around with that, that's fine, but the language is not 
going to change, so please to post code which uses your changes. If you start 
making changes to the compiler, you can't really expect other people to help 
you figure out what's wrong with your code - especially since your changes 
could be causing your problems (though I think that that's unlikely in this 
particular case).

> > 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.
> 
> I have, as you can see here:
> 
> [code]
> @property
> NotNull!(Foo) GetNN() {
> return this._nnf;
> }
> 
> alias GetNN this;
> [/code]
> 
> line 75 in my DPaste code.

Okay. I missed that, but that's probably your problem then. The definitions of 
of Foo and NotNull are recursive, which I don't believe is legal. It's almost 
certainly what's causing the compiler to eat up tons of CPU and memory and 
then die. In fact, if I fix the issue with Ptr returning a pointer to a class, 
and remove Foo's alias this and its associated function, the code compiles 
just fine with

 test_normal_foo(f2);

uncommented. Which in and of itself is disturbing, since there's no implicit 
conversion anymore. So, I think that there's definitely a bug there beyond the 
weird error that you're seeing.

> > 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.
> 
> I like it, this error detect null referenced as i wanted, that
> great!

Best case, the compiler can catch really, really simple cases such as

Foo foo;
foo.func();

It will never do more than that, because anything beyond the simple case 
requires extensive flow analysis, and it's impossible to do detect it if it's a 
function parameter, global variable, or static variable, because that would 
require checking across functions (and potentially a _lot_ of functions with 
_very_ extensive flow analysis), which pretty much no language does. So, you're 
_never_ going to get full null detection. It's essentially impossible. At 
best, you'll get it to catch a few simple cases.

However, the compiler doesn't even do that right now, so I don't know why 
you're getting the complaint about null dereferencing that you're getting.

> That's a bug i posted a while ago and i thougth that kenjii fix
> it in 2.060, or not?
> The compiler create an infinite loop and convert from Foo to
> NotNull!(Foo) and back and so on.
> If you create _one_ instance and returns them as pointer (or cast
> them as pointer, as you can se at my opCast method) the compiler
> breaks the conversion immediately. A little hack i detected and
> help me to realize the NotNull struct as i want. :)

Actually, it looks like it had been a few days since I updated my compiler. 
Now, if all I do is change Ptr to

 @property
 auto Ptr() {
 static if (isPointer!(T) || is(T == class)) {
 return this._val;
 } else {
 return &this._val;
 }
 }

then I get a segfault instead of dmd eating up CPU and memory, which is an 
improvement but not really acceptable, since the compiler isn't supposed to 
segfault. I don't know what the state of your bug report is, so I don't know 
if it's considered fixed or not.

- Jonathan M Davis