GCC Rich Locations

[philberty]

This relates to something I had thought about doing, but not in enough detail to open an enhancement issue. gcc supports something called "rich locations" in which three actual locations are encoded - a "start" location, a "caret" location, and an "end" location - basically like a location range with a specified value highlighted.

I couldn't find the page that I thought I originally read this in, but here's a quote from here:

As of GCC 6, ordinary locations changed from supporting just a point in the user’s source code to supporting three points: the caret location, plus a start and a finish:

      a = foo && bar;
          ~~~~^~~~~~
          |   |    |
          |   |    finish
          |   caret
          start

Instead of accessing start_location and end_location separately, these could be integrated into a single location value. There's also the technicality that the current definition of get_closing_locus() technically gets the beginning location of the last statement rather than the end location of the block (i.e. the right curly bracket), assuming that this would be the preferred behaviour.

The lexer would have to be modified to reflect this rich location system, and the parser and AST probably would have to be too (i.e. make a new location from the "start" location from one token and the "end" location of a different one). Also, the backend-independent Location abstraction would have to be modified to support this.

Originally posted by @SimplyTheOther in #90 (comment)

[davidmalcolm]

Strictly speaking, a rich_location is zero or more location_t, where a location_t has start, caret, and end. The rich_location can also optionally have per location_t-labels, along with zero or more fix-it hints. It's intended to be a short-lived on-stack object, for emitting diagnostics.

So I think initially you mean to populate the location_t with ranges, rather than points.

Sorry that I made the naming confusing.

[philberty]

One concept i think will help out AST and HIR will be to bring in the notion of Spans which rustc uses to solve this. Currently in our type inferencing code there are 2 messages for the case of expected i32 but got bool of example: one warning for the reference location and the other warning for where it was declared which is quite ugly and not right.