Support check mode for statics.

Support check mode for statics.
Committed: https://code.google.com/p/dart/source/detail?r=12187

[floitsch, 2012-09-10 09:26:51]

I'm still not convinced that this is the right way to go forward, but otherwise
LGTM.
My concerns:
1.
 final int x = "string"; will be a dynamic error the first time "x" is accessed.
Also: it will not assign "string" to the variable, but null (since the
initializer threw, and the semantics currently say that we then assign null to
it).

2.
 class A { const A(int x) : this.x = x; int x; }
 const A("string");
Afaics this is not yet caught. But that could be done in a separate CL.

3.
 class A { const A(this.x); var x; }
 const int foo = "string";
 const A a = const A(foo);
Afaics this will yield a "Not a compile-time constant error" and abort the
compilation. This is inconsistent with (1) where we only have a runtime error at
first access.

[kasperl, 2012-09-10 13:34:13]

LGTM. Do you think the test coverage for the areas Florian mentions is good
enough?

https://chromiumcodereview.appspot.com/10908143/diff/2001/tests/language/lang...
File tests/language/language_dart2js.status (right):

https://chromiumcodereview.appspot.com/10908143/diff/2001/tests/language/lang...
tests/language/language_dart2js.status:43: static_initializer_type_error_test:
Fail, Ok
Is it really OK to fail this test? Could the test be rewritten to check for
"unchecked" mode?

[ngeoffray, 2012-09-11 10:54:23]

PTAL. I have changed the code to get a compile-time error on final and const
fields, and a runtime error on other fields (that can be lazily initialized).
This matches the VM behavior and the spec, I believe.

[ngeoffray, 2012-09-11 10:58:27]

+karl, +peter

[kasperl, 2012-09-11 11:04:22]

https://chromiumcodereview.appspot.com/10908143/diff/6001/tests/language/stat...
File tests/language/static_initializer_type_error_test.dart (right):

https://chromiumcodereview.appspot.com/10908143/diff/6001/tests/language/stat...
tests/language/static_initializer_type_error_test.dart:8: bool inCheckedMode =
false;
Wouldn't it be cleaner to compute if we're in checked mode with a different
(simpler) method and then do something like:

   main() {
     if (inCheckedMode()) {
       Expect.throws(() => x, (e) => e is XXXException);
     } else {
       Expect.equals("milou", x);
     }
   }

   bool inCheckedMode() {
    int x; 
    try {
       x = true;
     } catch (e) {
       return true;
     }
     return false;
   }

[kasperl, 2012-09-11 11:05:52]

Even better:

if (inCheckedMode()) {
  Expect.throws(() => x, (e) => e is XXXException);
  Expect.isNull(x);
}

[kasperl, 2012-09-11 11:07:17]

LGTM. It would be nice with a test case that checks that we get the right
compile time errors for const stuff. For now, you may decide to also give
compile time errors for final things but it should really be a runtime error
long term because finals are lazily initialized.

[ngeoffray, 2012-09-11 11:57:31]

Thanks Kasper

Test added for what this change covers. I'll work on the other cases Florian
mentions in another CL.

https://chromiumcodereview.appspot.com/10908143/diff/6001/tests/language/stat...
File tests/language/static_initializer_type_error_test.dart (right):

https://chromiumcodereview.appspot.com/10908143/diff/6001/tests/language/stat...
tests/language/static_initializer_type_error_test.dart:8: bool inCheckedMode =
false;
On 2012/09/11 11:04:23, kasperl wrote:
> Wouldn't it be cleaner to compute if we're in checked mode with a different
> (simpler) method and then do something like:
> 
>    main() {
>      if (inCheckedMode()) {
>        Expect.throws(() => x, (e) => e is XXXException);
>      } else {
>        Expect.equals("milou", x);
>      }
>    }
> 
>    bool inCheckedMode() {
>     int x; 
>     try {
>        x = true;
>      } catch (e) {
>        return true;
>      }
>      return false;
>    }

I'd like not to change the test so much, and the test is mostly about line 16,
making sure we do not throw exception a second time.

I believe other tests use your "inCheckedMode()" trick for detecting ordinary
dynamic type error.