-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Fix invalid float literal suggestions when recovering an integer #105650
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
Conversation
@@ -0,0 +1,21 @@ | |||
fn main() {} | |||
|
|||
fn a() { |
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 if there's a better way to test errors like this other than putting them in separate functions/items.
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.
They can all go in a single function.
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.
Unfortunately it seems having two of these errors in a single function means only the first will be tested, which is why I had them in separate functions. Just curious if there's a more idiomatic way to do this, but I'm not seeing anything. Not blocking.
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.
How are you writing the test? There are lots of examples in the test suite with more than one error per function, e.g. src/test/ui/attrs-resolution-errors.rs. Also see https://rustc-dev-guide.rust-lang.org/tests/ui.html for docs about writing UI 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.
How are you writing the test?
Something like the following fails prematurely after the first error, hence the separate functions:
fn main() {
_ = .3u32;
//~^ ERROR expected expression, found `.`
_ = .0b0;
//~^ ERROR expected expression, found `.`
_ = .0o07;
//~^ ERROR expected expression, found `.`
_ = .0x0ABC;
//~^ ERROR expected expression, found `.`
}
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.
Oh, I see, it's nothing to do with the test harness, it's the parser itself no longer able to recover. Hmm.
@compiler-errors: This PR is about some error suggestions relating to invalid literals. E.g. if you have .3u32
the compiler current suggests:
error: float literals must have an integer part
--> c.rs:2:9
|
2 | _ = .3u32;
| ^^^^^ help: must have an integer part: `0.3u32`
But that suggestion is bogus, because 0.3u32
isn't a valid literal:
error: invalid suffix `u32` for float literal
--> c.rs:2:9
|
2 | _ = 0.3u32;
| ^^^^^^ invalid suffix `u32`
|
= help: valid suffixes are `f32` and `f64`
So I suggested that @cassaundra fix this, and this PR avoids the suggestion if the suffix isn't f32
/f64
, changing the error to:
error: expected expression, found `.`
--> c.rs:2:9
|
2 | _ = .3u32;
| ^ expected expression
This also prevents error recovery from happening, so any subsequent parse errors in the function aren't picked up.
Do you think this change is good enough as is? .3u32
is weird enough that I'm not sure if trying to recover makes sense, but I'm no expert on error messages.
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.
@nnethercote yes, failing the parse and consuming the rest of the block is unfortunate but acceptable. We can file a ticket to follow up on this and attempt to recover by discarding only until the ;
(which I thought we did already in statements, but there might be some reason it doesn't trigger here). Splitting the test in one function per unparseable case should be enough to get around this issue in the 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.
Looking good, just some minor suggestions.
@@ -0,0 +1,21 @@ | |||
fn main() {} | |||
|
|||
fn a() { |
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.
They can all go in a single function.
d4a886e
to
7497f7c
Compare
Discussion aside, requested comments have been added. |
@bors r+ (I think the test is fine. If we end up improving parser recovery to enable such tests to be more concise, that would be great, but I don't think it makes sense for that to block landing this PR.) |
…n, r=pnkfelix Fix invalid float literal suggestions when recovering an integer Only suggest adding a zero to integers with a preceding dot when the change will result in a valid floating point literal. For example, `.0x0` should not be turned into `0.0x0`. r? nnethercote
@bors r- |
@cassaundra This just needs to be updated for the recent |
Only suggest adding a zero to integers with a preceding dot when the change will result in a valid floating point literal. For example, `.0x0` should not be turned into `0.0x0`.
7497f7c
to
80fcd7c
Compare
Ah apologies, I missed that. Should be fixed now. |
@rustbot ready |
@bors r=pnkfelix |
☀️ Test successful - checks-actions |
Finished benchmarking commit (487e83b): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
|
Only suggest adding a zero to integers with a preceding dot when the change will result in a valid floating point literal.
For example,
.0x0
should not be turned into0.0x0
.r? nnethercote