Descent with compile-time debug for testing

[Ary Borenszweig]

Hi!

I just uploaded a new test version of Descent (0.5.6) with the new 
compile-time debugging feature. I tested it with some functions and 
templates and it seems to be working (but not with string mixins,) so I 
wanted you to play with it a little and see what you think, what could 
be improved or what is wrong, etc.

As always, you can update from Eclipse itself as described here:

http://www.dsource.org/projects/descent

And now a little explanation about how to get it working: right click on 
the function call or template instance you want to debug at 
compile-time, select Source -> Debug at Compile-Time, and that's it! The 
debugger interface will appear and you can step-into/over/return, or 
continue, place breakpoints (but not yet in external files, sorry,) and 
also it will break on errors, and you'll have the full stack trace to 
see what went wrong. :-)

(maybe I'll do a video about this later, for the curious)

Just note that if you do this:

---
int foo(int x) {
   return x * 2;
}

void main() {
   int x = foo(10);
}
---

if you try to debug "foo(10)", it will show the debugger interface, but 
stepping into will end the debugging session. Why? Because in the 
semantic analysis for that code, the call "foo(10)" isn't evaluated at 
compile time (as Descent just sneaks into the normal semantic analysis 
of the module.) For this you have to write:

void main() {
   const x = foo(10);
}

and now "foo(10)" is evalauted at compile time, since it's return value 
is assigned to a const value. ("const int" will also work.)

In the execution, you can see variables, analyze expressions (it 
supports any kinf of expression, like writing "1 + 2*3" will print "7".)

This is only for D1, in D2 it will not work as expected.

Enjoy!