Use messages for (some) public API errors

pkg/front_end/lib/src/fasta/kernel/verifier.dart

Index: pkg/front_end/lib/src/fasta/kernel/verifier.dart
diff --git a/pkg/front_end/lib/src/fasta/kernel/verifier.dart b/pkg/front_end/lib/src/fasta/kernel/verifier.dart
index c98e6bc03d7f476857f514e92e19fc0e82f17588..6ba4a583c231480360730dd99791be7485c13253 100644
--- a/pkg/front_end/lib/src/fasta/kernel/verifier.dart
+++ b/pkg/front_end/lib/src/fasta/kernel/verifier.dart
@@ -24,13 +24,14 @@ import 'package:kernel/verifier.dart' show VerificationError, VerifyingVisitor;
 
 import '../deprecated_problems.dart' show deprecated_printUnexpected;
 
+import '../fasta_codes.dart';
+
 import 'redirecting_factory_body.dart' show RedirectingFactoryBody;
 
-List<VerificationError> verifyProgram(Program program,
-    {bool isOutline: false}) {
+List<LocatedMessage> verifyProgram(Program program, {bool isOutline: false}) {

[Paul Berry, 2017/07/11 16:00:59]

I don't think it makes sense to use LocatedMessage here.  Verification errors
are internal errors and shouldn't use our user-visible error reporting
mechanism.

[Siggi Cherem (dart-lang), 2017/07/12 00:29:46]

I see your point and it is similar to the other error with compileSdk + summary
in ProcessedOptions.

Peter - what's your general opinion here? (for context, see also the discussion
on the other parts of the CL)

I was inclined to make all errors have an error code, unless the plan was to
stop the compiler immediately (e.g. like throwing). For throwing-like errors, we
can use problems.dart#unsupported, but if we can continue compilation after the
error, I expect to append it to an error list and keep going.

Verification errors might be the kind of error that should stop the compiler.

[Siggi Cherem (dart-lang), 2017/07/12 21:54:59]

Just to close the loop here - we started using "InternalProblem" prefix for all
kind of internal errors, so we can easily distinguish them and treat them in a
special way on our tools. We might want to add more in the API to expose when a
message is from an internal problem (other than the code name), though. Let's
keep iterating on this.

   FastaVerifyingVisitor verifier = new FastaVerifyingVisitor(isOutline);
   program.accept(verifier);
-  return verifier.errors;
+  return verifier.errors.map(convertError).toList();
 }
 
 class FastaVerifyingVisitor extends VerifyingVisitor
@@ -106,3 +107,13 @@ class FastaVerifyingVisitor extends VerifyingVisitor
     problem(null, "Unexpected appearance of the unknown type.");
   }
 }
+
+LocatedMessage convertError(VerificationError error) {
+  var node = error.node ?? error.context;
+  int offset = node?.fileOffset ?? -1;
+  var file = node?.location?.file;
+  Uri uri = file == null ? null : Uri.parse(file);
+  return templateVerificationError
+      .withArguments(error.details)
+      .withLocation(uri, offset);
+}