Use messages for (some) public API errors

pkg/front_end/lib/src/fasta/fasta_codes.dart

Index: pkg/front_end/lib/src/fasta/fasta_codes.dart
diff --git a/pkg/front_end/lib/src/fasta/fasta_codes.dart b/pkg/front_end/lib/src/fasta/fasta_codes.dart
index 67631e6aca2ec22dede2c0f5d669fdf7c84c8f63..86483550b4fd13521883efb065b9a445f7642e1a 100644
--- a/pkg/front_end/lib/src/fasta/fasta_codes.dart
+++ b/pkg/front_end/lib/src/fasta/fasta_codes.dart
@@ -6,6 +6,10 @@ library fasta.codes;
 
 import 'package:front_end/src/scanner/token.dart' show Token;
 
+import 'package:front_end/compilation_error.dart' show CompilationError;
+
+import 'package:source_span/source_span.dart' show SourceSpan, SourceLocation;
+
 part 'fasta_codes_generated.dart';
 
 class Code<T> {
@@ -66,7 +70,7 @@ class Template<T> {
   const Template({this.messageTemplate, this.tipTemplate, this.withArguments});
 }
 
-class LocatedMessage {
+class LocatedMessage implements CompilationError {

[Siggi Cherem (dart-lang), 2017/07/11 03:57:13]

Peter/Paul: a few questions for you here:

1- I would like to use messages.yaml for all of our errors, which means
practically that we'll use LocationMessage as the basic type we pass around in
the compiler and that eventually is used to produce errors publicly.

To report an error we could either wrap these message objects or do what I did
in this patchset. Looking ahead, it seems to me like we'll want to wrap: the
public API needs to include the notion of severity (error/warning/hint/nit) and
I don't believe that should go here. Especially because different tools may want
to adjust the severity of messages (e.g. treat warnings as errors).

What are your thoughts? do you agree with my thinking? If so, I'll update this
CL and wrap LocationMessage instead.

2- How do we want to publicly expose analyzer and dart2js codes? Should we
simply return the String in [Code]?

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

Wrapping LocationMessage sounds reasonable to me.
I'm not sure I understand the questino.  Let's discuss in person.

[ahe, 2017/07/12 13:14:43]

I agree. In fact, I just sent out CL 2974203002 which documents that messages
should be able to change severity. Also, I have a strong preference for wrapping
when it isn't performance critical.
I think we should just use a string (instead of an enum). A string is more
flexible, and I think flexibility is a must when it comes to getting everyone on
the same messages file.

   final Uri uri;
 
   final int charOffset;
@@ -81,5 +85,8 @@ class LocatedMessage {
 
   String get tip => messageObject.tip;
 
+  SourceSpan get span =>
+      new SourceLocation(charOffset, sourceUrl: uri).pointSpan();
+
   Map<String, dynamic> get arguments => messageObject.arguments;
 }