Avoid crashing on synthetic elements.

test/kernel/regression/unresolved_recovery.dart.txt

Index: test/kernel/regression/unresolved_recovery.dart.txt
diff --git a/test/kernel/regression/unresolved_recovery.dart.txt b/test/kernel/regression/unresolved_recovery.dart.txt
new file mode 100644
index 0000000000000000000000000000000000000000..ea90e7db8d4784866f79f8010ec689b90cb1cf04
--- /dev/null
+++ b/test/kernel/regression/unresolved_recovery.dart.txt
@@ -0,0 +1,19 @@
+library;
+import self as self;
+import "dart:core" as core;
+
+class E extends core::Object {
+  constructor •() → self::E
+    : super core::Object::•();
+  method foo() → dynamic {
+    let final dynamic #t1 = 4 in throw core::_unresolvedSuperMethodError@dart.core(this, #[]=, <dynamic>[#t1, 42], <dynamic, dynamic>{}, null);
+    let final dynamic #t2 = 4 in throw core::_unresolvedSuperMethodError@dart.core(this, #[]=, <dynamic>[#t2, (throw core::_unresolvedSuperMethodError@dart.core(this, #[], <dynamic>[#t2], <dynamic, dynamic>{}, null)).+(5)], <dynamic, dynamic>{}, null);
+    return let final dynamic #t3 = 2 in throw core::_unresolvedSuperMethodError@dart.core(this, #[], <dynamic>[#t3], <dynamic, dynamic>{}, null);
+  }
+}
+static method beforeTestMissingTry() → dynamic {
+  throw core::_genericNoSuchMethod@dart.core(null, #testMissingTry, <dynamic>[], <dynamic, dynamic>{}, null);

[asgerf, 2016/08/02 09:00:16]

Not a direct issue for this CL, but this really should be a call to the method
containing the syntax error, right?

After reading the docs for isSyntheticError I am thinking the semantic visitor
should dispatch this call as an ordinary resolved static call (i.e. it should
end up in handleStaticInvoke).  Otherwise every visitUnresolvedSomething will
have to do another step of disambiguation.

[ahe, 2016/08/02 12:59:35]

In principle, yes, but it's complicated and something I should fix eventually.
It has to do with error recovery.

Currently, the parser will mark any method that contains a parse error as being
malformed. The parser doesn't distinguish between unrecoverable errors and
recoverable errors, and it doesn't matter if we could parse the signature if we
ignored the method body.

So if there is a parse error, we may not be able to compute a function
signature. We should be able to come up with a better model for this, that's
also intuitive to use.

Just how bad the situation is wasn't clear to me when I wrote isSyntheticError,
and it isn't really fulfilling its potential.
FWIW, I noticed a typo in the documentation of isSyntheticError (it should say:
"However, returns *false* for elements that have an unrecoverable syntax
error.")

+}
+static method testMissingTry() → dynamic
+  invalid-statement;
+static method main() → dynamic {}