Call the compile-time constant handler inside bodies.

Call the compile-time constant handler inside bodies.

Don't transform a const instantiation into a 'new'.

Committed: https://code.google.com/p/dart/source/detail?r=5706

[ngeoffray, 2012-03-20 08:26:07]

LGTM

https://chromiumcodereview.appspot.com/9703074/diff/2001/frog/leg/compile_tim...
File frog/leg/compile_time_constants.dart (right):

https://chromiumcodereview.appspot.com/9703074/diff/2001/frog/leg/compile_tim...
frog/leg/compile_time_constants.dart:512: 
Why is this one not measuring anymore? Even if it calls a function that calls
measure, i think it should still do it.

[ahe, 2012-03-20 08:28:40]

LGTM

https://chromiumcodereview.appspot.com/9703074/diff/2001/frog/leg/compile_tim...
File frog/leg/compile_time_constants.dart (right):

https://chromiumcodereview.appspot.com/9703074/diff/2001/frog/leg/compile_tim...
frog/leg/compile_time_constants.dart:517: new CompileTimeConstantError(kind,
const []));
While trying to make our errors non-fatal, I noticed this would lead to a stack
overflow. Would it make sense to return "new NullConstant()"?

[ngeoffray, 2012-03-20 08:30:52]

https://chromiumcodereview.appspot.com/9703074/diff/2001/frog/leg/compile_tim...
File frog/leg/compile_time_constants.dart (right):

https://chromiumcodereview.appspot.com/9703074/diff/2001/frog/leg/compile_tim...
frog/leg/compile_time_constants.dart:517: new CompileTimeConstantError(kind,
const []));
On 2012/03/20 08:28:40, ahe wrote:
> While trying to make our errors non-fatal, I noticed this would lead to a
stack
> overflow. Would it make sense to return "new NullConstant()"?

IMO, I don't see any trouble in returning something here.

[floitsch, 2012-03-21 07:14:24]

https://chromiumcodereview.appspot.com/9703074/diff/2001/frog/leg/compile_tim...
File frog/leg/compile_time_constants.dart (right):

https://chromiumcodereview.appspot.com/9703074/diff/2001/frog/leg/compile_tim...
frog/leg/compile_time_constants.dart:512: 
On 2012/03/20 08:26:07, ngeoffray wrote:
> Why is this one not measuring anymore? Even if it calls a function that calls
> measure, i think it should still do it.

done.
Wanted to do the same for compileVariable, but this doesn't work. Maybe a vm
bug.

https://chromiumcodereview.appspot.com/9703074/diff/2001/frog/leg/compile_tim...
frog/leg/compile_time_constants.dart:517: new CompileTimeConstantError(kind,
const []));
On 2012/03/20 08:30:52, ngeoffray wrote:
> On 2012/03/20 08:28:40, ahe wrote:
> > While trying to make our errors non-fatal, I noticed this would lead to a
> stack
> > overflow. Would it make sense to return "new NullConstant()"?
> 
> IMO, I don't see any trouble in returning something here.

It could lead to another cryptic error right afterwards.

[ngeoffray, 2012-03-21 07:41:11]

https://chromiumcodereview.appspot.com/9703074/diff/2001/frog/leg/compile_tim...
File frog/leg/compile_time_constants.dart (right):

https://chromiumcodereview.appspot.com/9703074/diff/2001/frog/leg/compile_tim...
frog/leg/compile_time_constants.dart:517: new CompileTimeConstantError(kind,
const []));
On 2012/03/21 07:14:24, floitsch wrote:
> On 2012/03/20 08:30:52, ngeoffray wrote:
> > On 2012/03/20 08:28:40, ahe wrote:
> > > While trying to make our errors non-fatal, I noticed this would lead to a
> > stack
> > > overflow. Would it make sense to return "new NullConstant()"?
> > 
> > IMO, I don't see any trouble in returning something here.
> 
> It could lead to another cryptic error right afterwards.

Considering what Peter is trying to achieve (making our errors non-fatal),
that's a tautology :)

[ahe, 2012-03-21 10:13:37]

https://chromiumcodereview.appspot.com/9703074/diff/2001/frog/leg/compile_tim...
File frog/leg/compile_time_constants.dart (right):

https://chromiumcodereview.appspot.com/9703074/diff/2001/frog/leg/compile_tim...
frog/leg/compile_time_constants.dart:517: new CompileTimeConstantError(kind,
const []));
On 2012/03/21 07:14:24, floitsch wrote:
> On 2012/03/20 08:30:52, ngeoffray wrote:
> > On 2012/03/20 08:28:40, ahe wrote:
> > > While trying to make our errors non-fatal, I noticed this would lead to a
> > stack
> > > overflow. Would it make sense to return "new NullConstant()"?
> > 
> > IMO, I don't see any trouble in returning something here.
> 
> It could lead to another cryptic error right afterwards.

Which is definitely an improvement over the same error message repeated until
you get a stack overflow :-)

One proven technique is to return an erroneous element that shuts up the other
parts of the evaluator. I think returning a NullConstant is a good short-term
solution, possibly with a TODO.