-
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
in which we check for confusable Unicodepoints in float literal exponent #49989
in which we check for confusable Unicodepoints in float literal exponent #49989
Conversation
The `FatalError.raise()` might seem unmotivated (in most places in the compiler, `err.emit()` suffices), but it's actually used to maintain behavior (viz., stop lexing, don't emit potentially spurious errors looking for the next token after the bad Unicodepoint in the exponent): the previous revision's `self.err_span_` ultimately calls `Handler::emit`, which aborts if the `Handler`'s continue_after_error flag is set, which seems to typically be true during lexing (see `phase_1_parse_input` and and how `CompileController::basic` has `continue_parse_after_error: false` in librustc_driver). Also, let's avoid apostrophes in error messages (the present author would argue that users expect a reassuringly detached, formal, above-it-all tone from a Serious tool like a compiler), and use an RLS-friendly structured suggestion. Resolves rust-lang#49746.
Your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
The failing test might be due to |
👍 Intro programming students stumble over this all the time by copy/paste from a browser. |
Friendly triage ping, @zackmdavis. What is the status of this PR? Could look into the test failure and @estebank's question? |
Wednesday |
update: too sleepy to fix now (extant |
@zackmdavis no hurries. That restriction might merely be an oversight. If you see a path to fix it in this PR, feel free to go forward and add it, otherwise I would side step it and change the test to work regardless of |
Ping from triage, @zackmdavis ! Making sure you still have time to work on this PR. |
Thank you for this PR @zackmdavis! Unfortunately we haven't heard from you on this in a while, so I'm closing the PR to keep things tidy. Don't worry though, if you'll have time again in the future please reopen this PR, we'll be happy to review it again! |
The
FatalError.raise()
might seem unmotivated (in most places inthe compiler,
err.emit()
suffices), but it's actually used tomaintain behavior (viz., stop lexing, don't emit potentially spurious
errors looking for the next token after the bad Unicodepoint in the
exponent): the previous revision's
self.err_span_
ultimately callsHandler::emit
, which aborts if theHandler
's continue_after_errorflag is set, which seems to typically be true during lexing (see
phase_1_parse_input
and and howCompileController::basic
hascontinue_parse_after_error: false
in librustc_driver).Also, let's avoid apostrophes in error messages (the present author
would argue that users expect a reassuringly detached, formal,
above-it-all tone from a Serious tool like a compiler), and use an
RLS-friendly structured suggestion.
Resolves #49746.
r? @estebank