-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix overflow in error emitter #111745
Fix overflow in error emitter #111745
Conversation
(rustbot has picked a reviewer for you, use r? to override) |
// snippet being suggested, so that the *later* suggestions are correctly | ||
// aligned on the screen. Note that cur_hi and cur_lo can be on different | ||
// lines, so cur_hi.col can be smaller than cur_lo.col | ||
acc += len - (cur_hi.col.0 as isize - cur_lo.col.0 as isize); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this be simplified to len + cur_lo - cur_hi
? maybe that's conceptually not simpler, idk.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure, this could be acc += len - col_diff
, but it doesn't seem much cleaner to introduce a new variable. So I'll leave it like it is.
I already found the first bug thanks to the This test case: fn main() {
let a = 0.le('r',3.+0,3.+0, 3);
} Has an overflow because the spans overlap. The error message is mostly correct:
But these are the spans:
Note that this bug is already present in master, it is not caused by the changes in this PR. The spans overlap because they get expanded in the "delete next comma" logic from here:
Here are some logs that show how the spans are modified inside that function:
I tried to fix it by removing the "delete next comma" logic, and that fixes the overflow, but it breaks other tests. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please squash this into one commit. No use in keeping the revert in the history.
36be1c6
to
cbb4100
Compare
Thanks @bors r+ |
…piler-errors Fix overflow in error emitter Fix rust-lang#109854 Close rust-lang#94171 (was already fixed before but missing test) This bug happens when a multipart suggestion spans more than one line. The fix is to update the `acc` variable, which didn't handle the case when the text to remove spans multiple lines but the text to add spans only one line. Also, use `usize::try_from` instead of `as usize` to detect overflows earlier in the future, and point to the source of the overflow (the original issue points to a different place where this value is used, not where the overflow had happened). And finally add an `if start != end` check to avoid doing any extra work in case of empty ranges. Long explanation: Given this test case: ```rust fn generate_setter() { String::with_capacity( //~^ ERROR this function takes 1 argument but 3 arguments were supplied generate_setter, r#" pub(crate) struct Person<T: Clone> {} "#, r#""#, ); } ``` The compiler will try to convert that code into the following: ```rust fn generate_setter() { String::with_capacity( //~^ ERROR this function takes 1 argument but 3 arguments were supplied /* usize */, ); } ``` So it creates a suggestion with 3 separate parts: ``` // Replace "generate_setter" with "/* usize */" SubstitutionPart { span: fuzz_input.rs:4:5: 4:20 (#0), snippet: "/* usize */" } // Remove second arg (multiline string) SubstitutionPart { span: fuzz_input.rs:4:20: 7:3 (#0), snippet: "" } // Remove third arg (r#""#) SubstitutionPart { span: fuzz_input.rs:7:3: 8:11 (#0), snippet: "" } ``` Each of this parts gets a separate `SubstitutionHighlight` (this marks the relevant text green in a terminal, the values are 0-indexed so `start: 4` means column 5): ``` SubstitutionHighlight { start: 4, end: 15 } SubstitutionHighlight { start: 15, end: 15 } SubstitutionHighlight { start: 18446744073709551614, end: 18446744073709551614 } ``` The 2nd and 3rd suggestion are empty (start = end) because they only remove text, so there are no additions to highlight. But the 3rd span has overflowed because the compiler assumes that the 3rd suggestion is on the same line as the first suggestion. The 2nd span starts at column 20 and the highlight starts at column 16 (15+1), so that suggestion is good. But since the 3rd span starts at column 3, the result is `3 - 4`, or column -1, which turns into -2 with 0-indexed, and that's equivalent to `18446744073709551614 as isize`. With this fix, the resulting `SubstitutionHighlight` are: ``` SubstitutionHighlight { start: 4, end: 15 } SubstitutionHighlight { start: 15, end: 15 } SubstitutionHighlight { start: 15, end: 15 } ``` As expected. I guess ideally we shouldn't emit empty highlights when removing text, but I am too scared to change that.
…iaskrgr Rollup of 5 pull requests Successful merges: - rust-lang#111745 (Fix overflow in error emitter) - rust-lang#111770 (Read beta version from the version file if building from a source tarball) - rust-lang#111797 (Migrate GUI colors test to original CSS color format) - rust-lang#111809 (Unset MIRI_BLESS for mir-opt-level 4 miri tests) - rust-lang#111817 (Migrate GUI colors test to original CSS color format) r? `@ghost` `@rustbot` modify labels: rollup
Fix #109854
Close #94171 (was already fixed before but missing test)
This bug happens when a multipart suggestion spans more than one line.
The fix is to update the
acc
variable, which didn't handle the case when the text to remove spans multiple lines but the text to add spans only one line.Also, use
usize::try_from
instead ofas usize
to detect overflows earlier in the future, and point to the source of the overflow (the original issue points to a different place where this value is used, not where the overflow had happened).And finally add an
if start != end
check to avoid doing any extra work in case of empty ranges.Long explanation:
Given this test case:
The compiler will try to convert that code into the following:
So it creates a suggestion with 3 separate parts:
Each of this parts gets a separate
SubstitutionHighlight
(this marks the relevant text green in a terminal, the values are 0-indexed sostart: 4
means column 5):The 2nd and 3rd suggestion are empty (start = end) because they only remove text, so there are no additions to highlight. But the 3rd span has overflowed because the compiler assumes that the 3rd suggestion is on the same line as the first suggestion. The 2nd span starts at column 20 and the highlight starts at column 16 (15+1), so that suggestion is good. But since the 3rd span starts at column 3, the result is
3 - 4
, or column -1, which turns into -2 with 0-indexed, and that's equivalent to18446744073709551614 as isize
.With this fix, the resulting
SubstitutionHighlight
are:As expected. I guess ideally we shouldn't emit empty highlights when removing text, but I am too scared to change that.