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/rbltrlxsogrfxjzqf...@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