mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
4a8c5b20c7
rust/src/test/ui/did_you_mean/issue-49746-unicode-confusable-in-float-literal-expt.stderr

28 lines
1.3 KiB
Plaintext
Raw Normal View History

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.
2018-04-15 16:30:23 -05:00
error: expected at least one digit in exponent
Introduce rustc_lexer The idea here is to make a reusable library out of the existing rust-lexer, by separating out pure lexing and rustc-specific concerns, like spans, error reporting an interning. So, rustc_lexer operates directly on `&str`, produces simple tokens which are a pair of type-tag and a bit of original text, and does not report errors, instead storing them as flags on the token.
2019-05-06 03:53:40 -05:00
--> $DIR/issue-49746-unicode-confusable-in-float-literal-expt.rs:1:47
|
LL | const UNIVERSAL_GRAVITATIONAL_CONSTANT: f64 = 6.674e−11; // m³⋅kg⁻¹⋅s⁻²
| ^^^^^^
error: unknown start of token: \u{2212}
Remove licenses
2018-12-25 09:56:47 -06:00
--> $DIR/issue-49746-unicode-confusable-in-float-literal-expt.rs:1:53
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.
2018-04-15 16:30:23 -05:00
|
Fix test
2018-05-25 23:57:02 -05:00
LL | const UNIVERSAL_GRAVITATIONAL_CONSTANT: f64 = 6.674e−11; // m³⋅kg⁻¹⋅s⁻²
| ^
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.
2018-04-15 16:30:23 -05:00
help: Unicode character '−' (Minus Sign) looks like '-' (Minus/Hyphen), but it is not
|
Fix test
2018-05-25 23:57:02 -05:00
LL | const UNIVERSAL_GRAVITATIONAL_CONSTANT: f64 = 6.674e-11; // m³⋅kg⁻¹⋅s⁻²
| ^
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.
2018-04-15 16:30:23 -05:00
Allow lexer to recover from some homoglyphs
2019-07-24 18:10:42 -05:00
error[E0277]: cannot subtract `{integer}` from `{float}`
--> $DIR/issue-49746-unicode-confusable-in-float-literal-expt.rs:1:53
|
LL | const UNIVERSAL_GRAVITATIONAL_CONSTANT: f64 = 6.674e−11; // m³⋅kg⁻¹⋅s⁻²
| ^ no implementation for `{float} - {integer}`
|
= help: the trait `std::ops::Sub<{integer}>` is not implemented for `{float}`
error: aborting due to 3 previous errors
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.
2018-04-15 16:30:23 -05:00
Allow lexer to recover from some homoglyphs
2019-07-24 18:10:42 -05:00
For more information about this error, try `rustc --explain E0277`.
Reference in New Issue Copy Permalink