Overly aggressive inlining of Date expressions

Consider this JavaScript code:

console.log(
  (function() {
    var start = new Date().getTime();
    var end = new Date().getTime();
    return end - start;
  })()
);

Passing this through advanced optimizations yields

console.log((new Date).getTime()-(new Date).getTime());

which has different semantics: The unoptimized version will calculate an end date after the start date, and the difference will be non-negative. The optimized version will evaluate left to right, calculating the left date first, followed by the right date, producing non-positive values.

Example, using Nashorn:

jjs> (new Date).getTime()-(new Date).getTime()
-3

[mfikes]

@lazarljubenovic Yep, it is the result of a different optimization. This was found via ClojureScript, which can dynamically generate code (via a macro) to measure the length of time needed to evaluate an expression. If the thing you are measuring turns out to be trivial and gets (correctly) elided during advanced, then the inlining issue crops up.

[EatingW]

Created internal issue http://b/133856418