Add line numbers and columns to error messages spanning multiple files
If an error message is emitted that spans several files, only the
primary file currently has line and column data attached. This is
useful information, even in files other than the one in which the error
occurs. We can often work out which line and column the error
corresponds to in other files — in this case it is helpful to add them
(in the case of ambiguity, the first relevant line/column is picked,
which is still helpful than none).
If an error message is emitted that spans several files, only the
primary file currently has line and column data attached. This is
useful information, even in files other than the one in which the error
occurs. We can often work out which line and column the error
corresponds to in other files — in this case it is helpful to add them
(in the case of ambiguity, the first relevant line/column is picked,
which is still helpful than none).
fix mispositioned span
This fixes#47377
The output now looks like this
```
error[E0369]: binary operation `+` cannot be applied to type `&str`
--> h.rs:3:11
|
3 | let _a = b + ", World!";
| ^^^^^^^^^^^^^^ `+` can't be used to concatenate two `&str` strings
help: `to_owned()` can be used to create an owned `String` from a string reference. String concatenation appends the string on the right to the string on the left and may require reallocation. This requires ownership of the string on the left
|
3 | let _a = b.to_owned() + ", World!";
| ^^^^^^^^^
error: aborting due to previous error
```
For the case when emojis are involved, it gives the new output for proper indentation.
But for an indentation as follows,
```
fn main() {
let b = "hello";
let _a = b + ", World!";
}
```
it still mispositions the span
```
3 | println!("🦀🦀🦀🦀🦀"); let _a = b + ", World!";
| ^^^^^^^^^^^^^^ `+` can't be used to concatenate two `&str` strings
|
3 | println!("🦀🦀🦀🦀🦀"); let _a = b.to_owned() + ", World!";
| ^^^^^^^
error: aborting due to previous erro
```
cc @estebank @est31
Refactor internal suggestion API
~~The only functional change is that whitespace, which is suggested to be added, also gets `^^^^` under it. An example is shown in the tests (the only test that changed).~~
Continuation of #41876
r? @nagisa
the changes are probably best viewed [without whitespace](https://github.com/rust-lang/rust/pull/45741/files?w=1)
Fixes#44078. Fixes#44023.
The start_col member is given in chars,
while the code previously assumed it was given in bytes.
The more basic issue #44080 doesn't get fixed.
Point at `:` when using it instead of `;`
When triggering type ascription in such a way that we can infer a
statement end was intended, add a suggestion for the change. Always
point out the reason for the expectation of a type is due to type
ascription.
Fix#42057, #41928.
Now there's a way to add suggestions that hide the suggested code when
presented inline, to avoid weird wording when short code snippets are
added at the end.
When there're more than one suggestions in the same diagnostic, they are
displayed in their own block, instead of inline. In order to reduce
confusion, those blocks now display the line number.
Implement lazy loading of external crates' sources. Fixes#38875Fixes#38875. This is a follow-up to #42507. When a (now correctly translated) span from an external crate is referenced in a error, warning or info message, we still don't have the source code being referenced.
Since stuffing the source in the serialized metadata of an rlib is extremely wasteful, the following scheme has been implemented:
* File maps now contain a source hash that gets serialized as well.
* When a span is rendered in a message, the source hash in the corresponding file map(s) is used to try and load the source from the corresponding file on disk. If the file is not found or the hashes don't match, the failed attempt is recorded (and not retried).
* The machinery fetching source lines from file maps is augmented to use the lazily loaded external source as a secondary fallback for file maps belonging to external crates.
This required a small change to the expected stderr of one UI test (it now renders a span, where previously was none).
Further work can be done based on this - some of the machinery previously used to hide external spans is possibly obsolete and the hashing code can be reused in different places as well.
r? @eddyb
* The lazy loading mechanism has been moved to a more appropriate place.
* Return values from the functions invoked there are properly used.
* Documentation has gotten some minor improvements.
* Possibly some larger restructuring will need to take place still.
