diff options
| author | Zack M. Davis <code@zackmdavis.net> | 2018-04-15 14:30:23 -0700 |
|---|---|---|
| committer | Esteban Küber <esteban@kuber.com.ar> | 2018-05-25 20:48:31 -0700 |
| commit | 6437295b173a17361fdca1a45d2f9e7547cbc99f (patch) | |
| tree | 127b25cabc961c5d5ca67b7e207a69d52609ee03 /src/libsyntax/parse/parser.rs | |
| parent | 7426f5ccf7b362785a5abeb365674d3da3d4df2e (diff) | |
| download | rust-6437295b173a17361fdca1a45d2f9e7547cbc99f.tar.gz rust-6437295b173a17361fdca1a45d2f9e7547cbc99f.zip | |
in which we check for confusable Unicodepoints in float literal exponent
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 #49746.
Diffstat (limited to 'src/libsyntax/parse/parser.rs')
0 files changed, 0 insertions, 0 deletions
