Constant folding and runtime behavior have to agree.

[floitschG]

Currently the behavior for bit-operations differs for constant folded and runtime bit operations.
Example:
~1 != ~one(); // where one() return 1.

[rakudrama]

It is not just bit operations.

hide(x) => [x][0];
main() {
  var c = 100000000000000000000;
  var x = hide(100000000000000000000);
  print((c + 1) - c);
  print((x + 1) - x);
  print((100000000000000000000 + 1) - 100000000000000000000);
}

Prints:
1 // copy prop and constant fold
0 // evaluation
1 // constant expression

All three should be the same.

In code that evaluates, all constant folding should be done using both dart-full and execution (js) semantics.
If there is a discrepancy the compiler should pick the execution semantics, and if the expression is a constant expression the user should be warned.

It is a more difficult decision when the context demands a constant expression, but I think there too the 'correct' value is the incorrect value - e.g. changing 'const' to 'new' at a constructor call should not change the values passed to the constructor.

[rakudrama]

FWIW self-hosted frog was a little better with regards to consistency because the self-hosted constant folding was done using JavaScript arithmetic.

I think running tests on a self-hosted test of dart2js might help flush out constant folding issues.

[rakudrama]

Issue #3358 has been merged into this issue.

[floitschG]

Partial duplicate: issue #4551.
I leave it as separate bug, since 4551 can be solved without fixing this issue.

[floitschG]

https://chromiumcodereview.appspot.com/10825386/

---

Added Started label.

[kasperl]

Added this to the M1 milestone.

[floitschG]

Fixed in r11883.

---

Added Fixed label.