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

39 lines
1.7 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⁻²
| ^
Increase spacing for suggestions in diagnostics Make the spacing between the code snippet and verbose structured suggestions consistent with note and help messages.
2019-10-24 00:20:58 -05: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 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⁻²
Modify structured suggestion output * On suggestions that include deletions, use a diff inspired output format * When suggesting addition, use `+` as underline * Color highlight modified span
2021-06-21 21:07:19 -05: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 16:30:23 -05:00
bless tests
2022-08-28 01:27:31 -05:00
error[E0277]: cannot subtract `{integer}` from `{float}` in const contexts
Allow lexer to recover from some homoglyphs
2019-07-24 18:10:42 -05:00
--> $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}`
|
bless tests
2022-08-28 01:27:31 -05:00
= help: the trait `~const Sub<{integer}>` is not implemented for `{float}`
Refer to the TraitRef::identity in the message to be clearer
2022-03-26 21:02:07 -05:00
= help: the following other types implement trait `Sub<Rhs>`:
Mention implementers of unsatisfied trait When encountering an unsatisfied trait bound, if there are no other suggestions, mention all the types that *do* implement that trait: ``` error[E0277]: the trait bound `f32: Foo` is not satisfied --> $DIR/impl_wf.rs:22:6 | LL | impl Baz<f32> for f32 { } | ^^^^^^^^ the trait `Foo` is not implemented for `f32` | = help: the following other types implement trait `Foo`: Option<T> i32 str note: required by a bound in `Baz` --> $DIR/impl_wf.rs:18:31 | LL | trait Baz<U: ?Sized> where U: Foo { } | ^^^ required by this bound in `Baz` ``` Mention implementers of traits in `ImplObligation`s. Do not mention other `impl`s for closures, ranges and `?`.
2021-12-13 14:56:40 -06:00
<&'a f32 as Sub<f32>>
<&'a f64 as Sub<f64>>
<&'a i128 as Sub<i128>>
<&'a i16 as Sub<i16>>
Fix list length
2022-03-26 18:14:47 -05:00
<&'a i32 as Sub<i32>>
<&'a i64 as Sub<i64>>
<&'a i8 as Sub<i8>>
<&'a isize as Sub<isize>>
Mention implementers of unsatisfied trait When encountering an unsatisfied trait bound, if there are no other suggestions, mention all the types that *do* implement that trait: ``` error[E0277]: the trait bound `f32: Foo` is not satisfied --> $DIR/impl_wf.rs:22:6 | LL | impl Baz<f32> for f32 { } | ^^^^^^^^ the trait `Foo` is not implemented for `f32` | = help: the following other types implement trait `Foo`: Option<T> i32 str note: required by a bound in `Baz` --> $DIR/impl_wf.rs:18:31 | LL | trait Baz<U: ?Sized> where U: Foo { } | ^^^ required by this bound in `Baz` ``` Mention implementers of traits in `ImplObligation`s. Do not mention other `impl`s for closures, ranges and `?`.
2021-12-13 14:56:40 -06:00
and 48 others
Allow lexer to recover from some homoglyphs
2019-07-24 18:10:42 -05: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 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