Use messages for (some) public API errors

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

 // Copyright (c) 2017, 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.
 
 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> {
   final String name;
 
   final Template<T> template;
 
   final String analyzerCode;
 
   final String dart2jsCode;
@@ skipping 40 matching lines @@
 class Template<T> {
   final String messageTemplate;
 
   final String tipTemplate;
 
   final T withArguments;
 
   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;
 
   final Message messageObject;
 
   const LocatedMessage(this.uri, this.charOffset, this.messageObject);
 
   Code get code => messageObject.code;
 
   String get message => messageObject.message;
 
   String get tip => messageObject.tip;
 
+  SourceSpan get span =>
+      new SourceLocation(charOffset, sourceUrl: uri).pointSpan();
+
   Map<String, dynamic> get arguments => messageObject.arguments;
 }