nordic-dev.net/rust
nordic-dev.net/rust
2
0
Fork 0
mirror of https://github.com/rust-lang/rust.git synced 2024-11-23 07:14:28 +00:00
Code Issues Packages Projects Releases Wiki Activity
00497ad24b
rust/tests/ui/issues/issue-34334.stderr

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

39 lines
1.8 KiB
Plaintext
Raw Normal View History

add and update tests
2020-12-15 20:03:25 +00:00
error: expected one of `,`, `:`, or `>`, found `=`
--> $DIR/issue-34334.rs:2:29
Move some `compile-fail` tests to `ui`
2018-07-15 21:11:54 +00:00
|
Update tests
2019-03-09 12:03:44 +00:00
LL | let sr: Vec<(u32, _, _) = vec![];
Tweak unclosed generics errors Remove unnecessary span label for parse errors that already have a suggestion. Provide structured suggestion to close generics in more cases.
2023-11-15 00:18:26 +00:00
| -- ^ expected one of `,`, `:`, or `>`
| |
Move some `compile-fail` tests to `ui`
2018-07-15 21:11:54 +00:00
| while parsing the type for `sr`
Provide suggestion for missing `>` in a type parameter list When encountering an inproperly terminated type parameter list, provide a suggestion to close it after the last non-constraint type parameter that was successfully parsed. Fix #94058.
2022-03-01 19:40:48 +00:00
|
help: you might have meant to end the type parameters here
|
LL | let sr: Vec<(u32, _, _)> = vec![];
| +
Move some `compile-fail` tests to `ui`
2018-07-15 21:11:54 +00:00
pretty: trim paths of unique symbols If a symbol name can only be imported from one place for a type, and as long as it was not glob-imported anywhere in the current crate, we can trim its printed path and print only the name. This has wide implications on error messages with types, for example, shortening `std::vec::Vec` to just `Vec`, as long as there is no other `Vec` importable anywhere. This adds a new '-Z trim-diagnostic-paths=false' option to control this feature. On the good path, with no diagnosis printed, we should try to avoid issuing this query, so we need to prevent trimmed_def_paths query on several cases. This change also relies on a previous commit that differentiates between `Debug` and `Display` on various rustc types, where the latter is trimmed and presented to the user and the former is not.
2020-09-02 07:40:56 +00:00
error[E0277]: a value of type `Vec<(u32, _, _)>` cannot be built from an iterator over elements of type `()`
Point at method call when it is the source of the bound error
2022-12-11 22:49:50 +00:00
--> $DIR/issue-34334.rs:5:87
Recover from parse error in tuple syntax
2019-03-27 00:36:07 +00:00
|
LL | let sr2: Vec<(u32, _, _)> = sr.iter().map(|(faction, th_sender, th_receiver)| {}).collect();
Point at method call when it is the source of the bound error
2022-12-11 22:49:50 +00:00
| ^^^^^^^ value of type `Vec<(u32, _, _)>` cannot be built from `std::iter::Iterator<Item=()>`
Handle case of incomplete local ty more gracefully When encountering a local binding with a type that isn't completed, the parser will reach a `=` token. When this happen, consider the type "complete" as far as the parser is concerned to avoid further errors being emitted by parse recovery logic.
2020-07-14 17:35:59 +00:00
|
pretty: trim paths of unique symbols If a symbol name can only be imported from one place for a type, and as long as it was not glob-imported anywhere in the current crate, we can trim its printed path and print only the name. This has wide implications on error messages with types, for example, shortening `std::vec::Vec` to just `Vec`, as long as there is no other `Vec` importable anywhere. This adds a new '-Z trim-diagnostic-paths=false' option to control this feature. On the good path, with no diagnosis printed, we should try to avoid issuing this query, so we need to prevent trimmed_def_paths query on several cases. This change also relies on a previous commit that differentiates between `Debug` and `Display` on various rustc types, where the latter is trimmed and presented to the user and the former is not.
2020-09-02 07:40:56 +00:00
= help: the trait `FromIterator<()>` is not implemented for `Vec<(u32, _, _)>`
For a single impl candidate, try to unify it with error trait ref
2023-09-10 03:21:52 +00:00
= help: the trait `FromIterator<(u32, _, _)>` is implemented for `Vec<(u32, _, _)>`
Point out the actual mismatch error
2023-09-10 03:33:07 +00:00
= help: for that trait implementation, expected `(u32, _, _)`, found `()`
Mention only assoc types changes
2022-12-06 20:08:17 +00:00
note: the method call chain might not have had the expected associated types
Only point at methods that might be relevant
2022-12-07 22:16:37 +00:00
--> $DIR/issue-34334.rs:5:43
Provide associated type information in method chains When encountering an unmet obligation that affects a method chain, like in iterator chains where one of the links has the wrong associated type, we point at every method call and mention their evaluated associated type at that point to give context to the user of where expectations diverged from the code as written. ``` note: the expression is of type `Map<std::slice::Iter<'_, {integer}>, [closure@$DIR/invalid-iterator-chain.rs:12:18: 12:21]>` --> $DIR/invalid-iterator-chain.rs:12:14 | LL | vec![0, 1] | ---------- this expression has type `Vec<{integer}>` LL | .iter() | ------ associated type `std::iter::Iterator::Item` is `&{integer}` here LL | .map(|x| { x; }) | ^^^^^^^^^^^^^^^ associated type `std::iter::Iterator::Item` is `()` here ```
2022-12-06 17:34:24 +00:00
|
Account for method call chains split across multiple bindings
2022-12-07 19:11:06 +00:00
LL | let sr: Vec<(u32, _, _) = vec![];
| ------ this expression has type `Vec<(_, _, _)>`
...
Provide associated type information in method chains When encountering an unmet obligation that affects a method chain, like in iterator chains where one of the links has the wrong associated type, we point at every method call and mention their evaluated associated type at that point to give context to the user of where expectations diverged from the code as written. ``` note: the expression is of type `Map<std::slice::Iter<'_, {integer}>, [closure@$DIR/invalid-iterator-chain.rs:12:18: 12:21]>` --> $DIR/invalid-iterator-chain.rs:12:14 | LL | vec![0, 1] | ---------- this expression has type `Vec<{integer}>` LL | .iter() | ------ associated type `std::iter::Iterator::Item` is `&{integer}` here LL | .map(|x| { x; }) | ^^^^^^^^^^^^^^^ associated type `std::iter::Iterator::Item` is `()` here ```
2022-12-06 17:34:24 +00:00
LL | let sr2: Vec<(u32, _, _)> = sr.iter().map(|(faction, th_sender, th_receiver)| {}).collect();
Use `with_forced_trimmed_paths`
2022-12-11 19:38:43 +00:00
| ------ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `Iterator::Item` changed to `()` here
Account for method call chains split across multiple bindings
2022-12-07 19:11:06 +00:00
| |
Use `with_forced_trimmed_paths`
2022-12-11 19:38:43 +00:00
| `Iterator::Item` is `&(_, _, _)` here
Point at source of trait bound obligations in more places Be more thorough in using `ItemObligation` and `BindingObligation` when evaluating obligations so that we can point at trait bounds that introduced unfulfilled obligations. We no longer incorrectly point at unrelated trait bounds (`substs-ppaux.verbose.stderr`). In particular, we now point at trait bounds on method calls. We no longer point at "obvious" obligation sources (we no longer have a note pointing at `Trait` saying "required by a bound in `Trait`", like in `associated-types-no-suitable-supertrait*`). Address part of #89418.
2021-10-05 23:04:09 +00:00
note: required by a bound in `collect`
--> $SRC_DIR/core/src/iter/traits/iterator.rs:LL:COL
Recover from parse error in tuple syntax
2019-03-27 00:36:07 +00:00
Handle case of incomplete local ty more gracefully When encountering a local binding with a type that isn't completed, the parser will reach a `=` token. When this happen, consider the type "complete" as far as the parser is concerned to avoid further errors being emitted by parse recovery logic.
2020-07-14 17:35:59 +00:00
error: aborting due to 2 previous errors
Move some `compile-fail` tests to `ui`
2018-07-15 21:11:54 +00:00
Handle case of incomplete local ty more gracefully When encountering a local binding with a type that isn't completed, the parser will reach a `=` token. When this happen, consider the type "complete" as far as the parser is concerned to avoid further errors being emitted by parse recovery logic.
2020-07-14 17:35:59 +00:00
For more information about this error, try `rustc --explain E0277`.
Reference in New Issue Copy Permalink