Type checking for compile time constants fails in new test ConstInit5NegativeTest

[DartBot]

This issue was originally filed by zundel@google.com

---

The test is passing, but should give a compile time error.

final A = 1;
final B = "Hello";
final C = A + B; // error: sub-expressions of binary + must be numeric

int main() {
}

[ghost]

The test ConstInit5NegativeTest is bad,

If main is changed to:

int main() {
  print(C);
}

The error is:

'/sources/alldart/dart/runtime/Test.dart': Error: line 3 pos 11: initializer must be a compile time constant
final C = A + B; // error: sub-expressions of binary + must be numeric

The compiler is not required to report errors at first parse through the source, but can delay it until the moment that the definition is used.

---

Added Invalid label.

[DartBot]

This comment was originally written by zundel@google.com

---

See spec section 10.1, these are compile time constants and should generate compile time errors.

---

Added New label.

[DartBot]

This comment was originally written by @mhausner

---

C does not get compiled until it's referenced. The spec allows this freedom in the implementation.

[ghost]

4 Errors and Warnings

…A compile-time error must be reported by a Dart compiler before the erroneous code is executed.

ConstInit5NegativeTest does not execute the getter of final C.

---

Added Invalid label.

[DartBot]

This comment was originally written by zundel@google.com

---

OK, thanks for the clarification. I'll update the test and shift this bug to Frog which does try to execute the code.

---

Removed Area-VM label.
Added Area-Frog label.

[ghost]

I think that the spec allows for an earlier error reporting than VM does. It mandates only the latest point in time that it must be reported.

[DartBot]

This comment was originally written by zundel@google.com

---

Updated test.

final A = 1;
final B = "Hello";
final C = A + B; // error: sub-expressions of binary + must be numeric

int main() {
  try {
    // Some Dart implementations may not check C until it is about to be executed
    print(C);
  } catch (Exception e) {
    // should be a compilation error, not a catchable exception
  }
}

Frog still throws a NSME instead of what looks like a compile-time exception, but its in a place that can't be caught (the assignment of C). I'm going to close out the bug. There are still ongoing discussions about the best ways to test for compile-time errors in the unit test framework.