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 21:30:23 +00:00
|
|
|
|
error: expected at least one digit in exponent
|
2019-05-06 08:53:40 +00: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}
|
2018-12-25 15:56:47 +00: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 21:30:23 +00:00
|
|
|
|
|
|
2018-05-26 04:57:02 +00:00
|
|
|
|
LL | const UNIVERSAL_GRAVITATIONAL_CONSTANT: f64 = 6.674e−11; // m³⋅kg⁻¹⋅s⁻²
|
|
|
|
|
| ^
|
2019-10-24 05:20:58 +00:00
|
|
|
|
|
|
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 21:30:23 +00:00
|
|
|
|
help: Unicode character '−' (Minus Sign) looks like '-' (Minus/Hyphen), but it is not
|
|
|
|
|
|
|
2018-05-26 04:57:02 +00:00
|
|
|
|
LL | const UNIVERSAL_GRAVITATIONAL_CONSTANT: f64 = 6.674e-11; // m³⋅kg⁻¹⋅s⁻²
|
2021-06-22 02:07:19 +00:00
|
|
|
|
| ~
|
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 21:30:23 +00:00
|
|
|
|
|
2019-07-24 23:10:42 +00: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}`
|
|
|
|
|
|
|
2020-09-02 07:40:56 +00:00
|
|
|
|
= help: the trait `Sub<{integer}>` is not implemented for `{float}`
|
2019-07-24 23:10:42 +00:00
|
|
|
|
|
|
|
|
|
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 21:30:23 +00:00
|
|
|
|
|
2019-07-24 23:10:42 +00:00
|
|
|
|
For more information about this error, try `rustc --explain E0277`.
|