Indicate origin of where type parameter for uninferred types #67285
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rust-highfive
added
the
S-waiting-on-review
ohadravid
changed the title
estebank
approved these changes
Dec 13, 2019
ohadravid
force-pushed
the
indicate-origin-of-where-type-parameter
branch
2 times, most recently
from
ed42b11
to
3a08b8a
Compare
|
r=me |
ohadravid
force-pushed
the
indicate-origin-of-where-type-parameter
branch
from
3a08b8a
to
8a4632d
Compare
|
@estebank done! CI is green, the PR is rebased 🎉 |
|
@bors r+ |
|
📌 Commit 8a4632d has been approved by |
bors
added
S-waiting-on-bors
Centril
added a commit
to Centril/rust
that referenced
this pull request
Dec 15, 2019
…type-parameter, r=estebank Indicate origin of where type parameter for uninferred types Based on rust-lang#65951 (which is not merge yet), fixes rust-lang#67277. This PR improves a little the diagnostic for code like: ``` async fn foo() { bar().await; } async fn bar<T>() -> () {} ``` by showing: ``` error[E0698]: type inside `async fn` body must be known in this context --> unresolved_type_param.rs:9:5 | 9 | bar().await; | ^^^ cannot infer type for type parameter `T` declared on the function `bar` | ... ``` (The ``` declared on the function `bar` ``` part is new) A small side note: `Vec` and `slice` seem to resist this change, because querying `item_name()` panics, and `get_opt_name()` returns `None`. r? @estebank
Centril
added a commit
to Centril/rust
that referenced
this pull request
Dec 15, 2019
…type-parameter, r=estebank Indicate origin of where type parameter for uninferred types Based on rust-lang#65951 (which is not merge yet), fixes rust-lang#67277. This PR improves a little the diagnostic for code like: ``` async fn foo() { bar().await; } async fn bar<T>() -> () {} ``` by showing: ``` error[E0698]: type inside `async fn` body must be known in this context --> unresolved_type_param.rs:9:5 | 9 | bar().await; | ^^^ cannot infer type for type parameter `T` declared on the function `bar` | ... ``` (The ``` declared on the function `bar` ``` part is new) A small side note: `Vec` and `slice` seem to resist this change, because querying `item_name()` panics, and `get_opt_name()` returns `None`. r? @estebank
bors
added a commit
that referenced
this pull request
Dec 15, 2019
Rollup of 6 pull requests Successful merges: - #65778 (Stabilize `std::{rc,sync}::Weak::{weak_count, strong_count}`) - #66570 (stabilize Result::map_or) - #67206 (Update cargo, books) - #67285 (Indicate origin of where type parameter for uninferred types ) - #67317 (fix type_name_of_val doc comment) - #67324 (Fix repetition in matches/mod.rs) Failed merges: r? @ghost
|
⌛ Testing commit 8a4632d with merge 8c51da8582a54d63bca13d59dc4817b02ab71aa9... |
|
Your PR failed (pretty log, raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
💔 Test failed - checks-azure |
bors
added
S-waiting-on-review
|
@bors retry |
bors
added
S-waiting-on-bors
Centril
added a commit
to Centril/rust
that referenced
this pull request
Dec 20, 2019
…type-parameter, r=estebank Indicate origin of where type parameter for uninferred types Based on rust-lang#65951 (which is not merge yet), fixes rust-lang#67277. This PR improves a little the diagnostic for code like: ``` async fn foo() { bar().await; } async fn bar<T>() -> () {} ``` by showing: ``` error[E0698]: type inside `async fn` body must be known in this context --> unresolved_type_param.rs:9:5 | 9 | bar().await; | ^^^ cannot infer type for type parameter `T` declared on the function `bar` | ... ``` (The ``` declared on the function `bar` ``` part is new) A small side note: `Vec` and `slice` seem to resist this change, because querying `item_name()` panics, and `get_opt_name()` returns `None`. r? @estebank
Centril
added a commit
to Centril/rust
that referenced
this pull request
Dec 20, 2019
…type-parameter, r=estebank Indicate origin of where type parameter for uninferred types Based on rust-lang#65951 (which is not merge yet), fixes rust-lang#67277. This PR improves a little the diagnostic for code like: ``` async fn foo() { bar().await; } async fn bar<T>() -> () {} ``` by showing: ``` error[E0698]: type inside `async fn` body must be known in this context --> unresolved_type_param.rs:9:5 | 9 | bar().await; | ^^^ cannot infer type for type parameter `T` declared on the function `bar` | ... ``` (The ``` declared on the function `bar` ``` part is new) A small side note: `Vec` and `slice` seem to resist this change, because querying `item_name()` panics, and `get_opt_name()` returns `None`. r? @estebank
bors
added a commit
that referenced
this pull request
Dec 20, 2019
Rollup of 7 pull requests Successful merges: - #66755 (Remove a const-if-hack in RawVec) - #67127 (Use structured suggestion for disambiguating method calls) - #67219 (Fix up Command Debug output when arg0 is specified.) - #67285 (Indicate origin of where type parameter for uninferred types ) - #67328 (Remove now-redundant range check on u128 -> f32 casts) - #67367 (Move command line option definitions into a dedicated file) - #67442 (Remove `SOCK_CLOEXEC` dummy variable on platforms that don't use it.) Failed merges: r? @ghost
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Based on #65951 (which is not merge yet), fixes #67277.
This PR improves a little the diagnostic for code like:
by showing:
(The
part is new)
A small side note:
Vecandsliceseem to resist this change, because queryingitem_name()panics, andget_opt_name()returnsNone.r? @estebank