Migrate test block 7 to Dart 2.0.

tests/corelib_2/error_stack_trace_test.dart

 // Copyright (c) 2013, the Dart project authors.  Please see the AUTHORS file
 // for details. All rights reserved. Use of this source code is governed by a
 // BSD-style license that can be found in the LICENSE file.
 
 import "package:expect/expect.dart";
 
 void argument() {
   throw new ArgumentError(499);
 }
 

[Bob Nystrom, 2017/07/25 22:05:43]

Oof, this test is complicated. I believe the intent here is to cause the runtime
to throw one of each of the various exception classes that extend Error. Then,
for each of those, validate that it has a .stackTrace property that returns a
non-null stack trace.

Some of these errors will disappear entirely in 2.0 because they are reported
statically an no longer need to be thrown at runtime. For those, I think you can
delete the code in question. Others can still be thrown randomly, but you might
need some explicit "dynamic" to avoid hitting a static error first. The rest
should be fine as-is.

I don't think you'll need to split out the static errors into a separate
multitest.

In more detail...

[jcollins, 2017/08/02 21:03:26]

Acknowledged.

 void noSuchMethod() {
-  (499).doesNotExist();
+  (499).doesNotExist(); //# static: compile-time error

[Bob Nystrom, 2017/07/25 22:05:43]

This is still a valid runtime error, but we need to shut up the type checker
first. This should do it:

(499 as dynamic).doesNotExist();

[jcollins, 2017/08/02 21:03:26]

So, in other words, in Dart 2.0 the only time a runtime error for non-existent
methods can happen is on dynamic declared types, and you think this test was
actually intended to catch just that?  If so, that works for me.  Done.

[Bob Nystrom, 2017/08/02 21:12:36]

Exactly right.
Yup!

 }
 
 void nullThrown() {
   throw null;
 }
 
 void range() {
   throw new RangeError.range(0, 1, 2);
 }
 
 void fallThrough() {

[Bob Nystrom, 2017/07/25 22:05:43]

FallThrough errors should not exist at runtime in Dart 2.0. You can kill this
entire function and the code that references it.

   nested() {}
 
   switch (5) {
-    case 5:
-      nested();
+    case 5://# static: compile-time error
+      nested();//# static: compile-time error

[jcollins, 2017/08/02 21:03:26]

This case has become more interesting once we've peeled back the other ones. 
dartdevc is the only compiler that gives an error here; the analyzer gives
static warnings.  It suggests to me that the case is interesting in some way if
for no other reason than the different behavior, so I'm inclined not to drop it,
but will defer to your judgment on that.

[Bob Nystrom, 2017/08/02 21:12:36]

In strong mode, that static warning should get promoted to a static error. Once
strong mode is the only mode, there won't be a way to see this as a warning any
more.
We probably have other cases where the existing behavior diverges for features
that are no longer supported by Dart 2.0, but that doesn't mean we need to keep
the test around. Part of the reason for going to Dart 2.0 is to end up with a
simpler system with less surface area to worry about, so deleting those tests is
a good thing — it means there's less opportunity for divergence in the first
place. :)

You can remove this code. As I understand it, FallThroughError literally won't
exist as a type in the Dart 2.0 core library, just like
AbstractClassInstantiationError.

     default:
       Expect.fail("Should not reach");
   }
 }
 
 abstract class A {
   foo();
 }
 

[Bob Nystrom, 2017/07/25 22:05:43]

Likewise, there is no AbstractClassInstantiationError in Dart 2.0. Delete this
fn.

[jcollins, 2017/08/02 21:03:26]

done

 void abstractClassInstantiation() {
-  new A();
+  new A();//# static: compile-time error
 }
 
 void unsupported() {
   throw new UnsupportedError("unsupported");
 }
 
 void unimplemented() {
   throw new UnimplementedError("unimplemented");
 }
 
 void state() {
-  return [1, 2].single;
+  return [1, 2].single;//# static: compile-time error

[Bob Nystrom, 2017/07/25 22:05:43]

As far as I can tell, this shouldn't have a static error. We do want to test
this case, but I think the previous code will be statically clean and throw a
runtime StateError like we want.

[jcollins, 2017/08/02 21:03:26]

This has a static error because the code returns an integer instead of a void. 
Altered based on your reading of what the purpose of this test is to return a
dynamic, thus creating a runtime error.

[Bob Nystrom, 2017/08/02 21:12:36]

Ha, oh, right.
For this function, it just needs to *throw* a StateError. Calling single on a
list with more than one item will do that. I'd just remove the return:

void state() {
  [1, 2].single;
}

(If you want to be more minimal, [].first also throws a StateError.)

[jcollins, 2017/08/03 15:54:18]

Making this more minimal makes sense, done.

 }
 
 void type() {
-  return 1 + "string";
+  return 1 + "string";//# static: compile-time error

[Bob Nystrom, 2017/07/25 22:05:43]

I don't believe Dart 2.0 has TypeError. But it *does* have CastError, which this
test doesn't seem to cast, but should. How about changing this to:

void cast() {
  dynamic d = 1;
  d as String;
}

[jcollins, 2017/08/02 21:03:25]

Done.

 }
 
 main() {
   List<Function> errorFunctions = [
     argument,
-    noSuchMethod,
+    noSuchMethod, //# static: ok
     nullThrown,
     range,
-    fallThrough,
-    abstractClassInstantiation,
+    fallThrough, //# static: ok
+    abstractClassInstantiation,  //# static: ok
     unsupported,
     unimplemented,
-    state,
-    type
+    state, //# static: ok
+    type //# static: ok
   ];
 
   for (var f in errorFunctions) {
     bool hasThrown = false;
     try {
       f();
-    } catch (e) {
+    } catch (e, stackTrace) {
       hasThrown = true;
       Expect.isTrue(
-          e.stackTrace is StackTrace, "$e doesn't have a non-null stack trace");
+          stackTrace is StackTrace, "$e doesn't have a non-null stack trace");

[Bob Nystrom, 2017/07/25 22:05:43]

I don't think this change is right. My reading is that this test is about
validating that Error itself does have a .stackTrace property.

[jcollins, 2017/08/02 21:03:26]

I had asked around about this and the understanding I got was that the use of
the stackTrace property was obsolete.    Combine that with the fact that
dartdevc didn't have it in one case, I had inferred, perhaps incorrectly, that
Dart 2.0 no longer cares about that property.  Instead, extracted that case into
a multitest and will file a bug assuming that this is right.

[Bob Nystrom, 2017/08/02 21:12:36]

Oh, interesting. I didn't realize there were any API changes to Error itself. It
might be good to tease those apart from the test migration, but I'll defer to
you on that.

[jcollins, 2017/08/03 15:54:18]

Since I've already done the work of figuring out what case this is, might as
well leave a bread crumb or two.

     }
     Expect.isTrue(hasThrown);
   }
 }