diff options
author | Matthias Krüger <matthias.krueger@famsik.de> | 2023-03-02 23:05:28 +0100 |
---|---|---|
committer | GitHub <noreply@github.com> | 2023-03-02 23:05:28 +0100 |
commit | 564715a5b7fa43dbdca96b49d0086ac7a2d76b58 (patch) | |
tree | 30b4595ecab7e3b77a87b07315c8ab68bcfa3313 /tests/rustdoc-js-std/parser-errors.js | |
parent | a27a4e4c7ab5dc2315dacef717e3baaba409c53b (diff) | |
parent | be15f174fa13386a1b5f69fedbe0301c84d3df4d (diff) | |
download | rust-564715a5b7fa43dbdca96b49d0086ac7a2d76b58.tar.gz |
Rollup merge of #108557 - Nathan-Fenner:nathanf/adjust-error-span-fix-Some, r=WaffleLapkin
Point error span at Some constructor argument when trait resolution fails
This is a follow up to #108254 and #106477 which extends error span refinement to handle a case which I mistakenly believed was handled in #106477. The goal is to refine the error span depicted below:
```rs
trait Fancy {}
impl <T> Fancy for Option<T> where T: Iterator {}
fn want_fancy<F>(f: F) where F: Fancy {}
fn example() {
want_fancy(Some(5));
// (BEFORE) ^^^^^^^ `{integer}` is not an iterator
// (AFTER) ^ `{integer}` is not an iterator
}
```
I had used a (slightly more complex) example as an illustrative example in #108254 , but hadn't actually turned it into a test, because I had (incorrectly) believed at the time it was covered by existing behavior. It turns out that `Some` is slightly "special" in that it resolves differently from the other `enum` constructors I had tried, and therefore this test was actually broken.
I've now updated the tests to include this example, and fixed the code to correctly resolve the `Some` constructor so that the span of the error is reduced.
Diffstat (limited to 'tests/rustdoc-js-std/parser-errors.js')
0 files changed, 0 insertions, 0 deletions