Associate source and location information with errors

[bwilkerson]

The class DartCompilationError is intended to carry along information about both which source file contains the error and the location in the file where the error occurs. These pieces of information are sometimes missing, which prevents the editor from being able to navigate to the source of the error, reducing the usability of the editor. (I believe it also reduces the usability of the command-line version by making it impossible to report those pieces of information.)

My recommendation is that we remove the constructors that do not take both a source and a location and that we add tests to ensure that these arguments are non-null. This will, of course, require updating all existing error creation sites to ensure that this information is passed along.

[bwilkerson]

Removed the owner.

[DartBot]

This comment was originally written by johnle...@google.com

---

Brian can you provide a code sample that would demonstrate the problem? Or build a test case?

[bwilkerson]

Brian can you provide a code sample that would demonstrate the problem? Or build a test case?

It would be difficult to provide a test case for all possible problems, because we'd have to have code that would produce every possible compilation error. For example, one way to produce such a compilation error is with code of the form:

    void main(String arg) {
      ...
    }

This will produce a compilation error that has neither source nor location information. (As a work-around, when the editor finds such an object it will use the file that defines the library as a substitute for the source location and zero (0) as a substitute for the location, which sometimes appears to be right, such as in this case, but isn't right in general.)

I can provide code samples for specific cases, but to find all of the cases I'd basically have to trace the possible call sites for every constructor and look at those invocations to see whether the source and location information are being supplied (and then figure out what code would get me to that point). Eliminating the constructors that don't allow this information to be passed in and adding assertions that the information is useful (not null, and in the case of location information not equal to Location.NONE) would probably take care of most of the issues.

[DartBot]

This comment was originally written by johnle...@google.com

---

Just one will do to start.

[DartBot]

This comment was originally written by johnle...@google.com

---

Set owner to johnle...@google.com.

[DartBot]

This comment was originally written by johnle...@google.com

---

r533

---

Added Fixed label.