nordic-dev.net/rust
nordic-dev.net/rust
2
0
Fork 0
mirror of https://github.com/rust-lang/rust.git synced 2024-11-01 06:51:58 +00:00
Code Issues Packages Projects Releases Wiki Activity
917662a8f6
rust/tests/ui/did_you_mean/issue-49746-unicode-confusable-in-float-literal-expt.stderr

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

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 21:30:23 +00: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 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}
Remove licenses
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
|
Fix test
2018-05-26 04:57:02 +00: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 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
|
Fix test
2018-05-26 04:57:02 +00: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-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
bless tests
2022-08-28 06:27:31 +00:00
error[E0277]: cannot subtract `{integer}` from `{float}` in const contexts
Allow lexer to recover from some homoglyphs
2019-07-24 23:10:42 +00: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 06:27:31 +00: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-27 02:02:07 +00: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 20:56:40 +00: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 23:14:47 +00: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 20:56:40 +00:00
and 48 others
Allow lexer to recover from some homoglyphs
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
Allow lexer to recover from some homoglyphs
2019-07-24 23:10:42 +00:00
For more information about this error, try `rustc --explain E0277`.
Reference in New Issue Copy Permalink