Uh oh!
There was an error while loading. Please reload this page.
Indicate origin of where type parameter for uninferred types - #67285
Conversation
estebank
left a comment
There was a problem hiding this comment.
Looks good to me!
Left some formatting nitpicks, but r=me once CI is green and the parent PR has landed.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
ed42b11 to
3a08b8aCompareestebank
commented
Dec 13, 2019
r=me |
3a08b8a to
8a4632dCompareohadravid
commented
Dec 14, 2019
@estebank done! CI is green, the PR is rebased 🎉 |
estebank
commented
Dec 14, 2019
@bors r+ |
bors
commented
Dec 14, 2019
📌 Commit 8a4632d has been approved by |
…type-parameter, r=estebank Indicate origin of where type parameter for uninferred types Based on rust-lang#65951 (which is not merge yet), fixesrust-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
…type-parameter, r=estebank Indicate origin of where type parameter for uninferred types Based on rust-lang#65951 (which is not merge yet), fixesrust-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
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
bors
commented
Dec 16, 2019
⌛ Testing commit 8a4632d with merge 8c51da8582a54d63bca13d59dc4817b02ab71aa9... |
rust-highfive
commented
Dec 16, 2019
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 |
bors
commented
Dec 16, 2019
💔 Test failed - checks-azure |
Centril
commented
Dec 16, 2019
@bors retry |
…type-parameter, r=estebank Indicate origin of where type parameter for uninferred types Based on rust-lang#65951 (which is not merge yet), fixesrust-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
…type-parameter, r=estebank Indicate origin of where type parameter for uninferred types Based on rust-lang#65951 (which is not merge yet), fixesrust-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
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
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