rustc_typeck: improve diagnostics for -> _ fn return type #62694
Conversation
This comment has been minimized.
This comment has been minimized.
rust-highfive
added
the
S-waiting-on-review
| | ^ | ||
| | | | ||
| | not allowed in type signatures | ||
| | help: replace `_` with the correct return type: `i32` | ||
|
|
||
| error[E0121]: the type placeholder `_` is not allowed within types on item signatures |
There was a problem hiding this comment.
Heh, you could also implement it for const/static with type _.
There was a problem hiding this comment.
We could also add parser recovery for when no type is provided syntactically, for example: const FOO = 42;. I think more people would attempt that. But this could be done in a follow up.
There was a problem hiding this comment.
Help for const FOO = 42; looks nice, that's how I usually forget about it in const's, though I'm not sure what'd be the correct parser recovery, replacing the type with Infer and then failing here with proper help?
There was a problem hiding this comment.
Yes, basically delegate to the AST representation of const $name: _ = $expr; and make sure to error in the parser.
There was a problem hiding this comment.
@Centril But would we have the correct type to suggest in the parser? (I assume you implied the type of self.parse_expr() on the right side of const declaration)
There was a problem hiding this comment.
The correct type in the parser would be Infer.
There was a problem hiding this comment.
But then the suggestion for const FOO = 42 would be the same as for const FOO: _ = 42 - to replace the _ even though the user hasn't written it, could we perhaps denote some sort of type-absence to handle that properly? Or am I misunderstanding something?
There was a problem hiding this comment.
Yeah, let's follow up later.
@lundibundi We should take care not to suggest replacing _ with something since the user did not write that. Instead we should indicate that the type is missing and that we think the type is so and so.
src/librustc_typeck/collect.rs
Outdated
| ); | ||
| } | ||
| diag.emit(); | ||
| ty::Binder::bind(*tables.liberated_fn_sigs().get(hir_id).unwrap()) |
There was a problem hiding this comment.
Hmm, you could also get the return type from here, instead of from the body. Not sure which is better, cc @matthewjasper @nikomatsakis
There was a problem hiding this comment.
I think it would be at least more 'correct' since we are suggesting the return type of this function and not the 'body' and since we already have it might as well use it.
Edit: Pushed as a separate commit.
lundibundi
force-pushed
the
help-infer-fn-ret
branch
from
1ba0dbe
to
be9898e
Compare
This comment has been minimized.
This comment has been minimized.
lundibundi
force-pushed
the
help-infer-fn-ret
branch
from
be9898e
to
f8681f0
Compare
|
Merged fixups and rebased on master as there were quite many fixups! and GitHub displayed the commits in the wrong order anyway. |
|
@bors r+ |
|
📌 Commit f8681f0 has been approved by |
bors
added
S-waiting-on-bors
rustc_typeck: improve diagnostics for -> _ fn return type This should implement IIUC the mentioned issue. ~~I'm not sure if there is a better way than `get_infer_ret_ty` to get/check the return type without code duplication.~~ ~~Also, is this unwrap be okay `ty::Binder::bind(*tables.liberated_fn_sigs().get(hir_id).unwrap())`?~~ r? @eddyb Closes: #56132
|
☀️ Test successful - checks-azure |
… r=eddyb rustc_typeck: improve diagnostics for _ const/static declarations This continues rust-lang#62694 and adds type suggestions to const/static declarations with `_` type. r? @eddyb
… r=eddyb rustc_typeck: improve diagnostics for _ const/static declarations This continues rust-lang#62694 and adds type suggestions to const/static declarations with `_` type. r? @eddyb
… r=eddyb rustc_typeck: improve diagnostics for _ const/static declarations This continues rust-lang#62694 and adds type suggestions to const/static declarations with `_` type. r? @eddyb
This should implement IIUC the mentioned issue.
I'm not sure if there is a better way thanget_infer_ret_tyto get/check the return type without code duplication.Also, is this unwrap be okayty::Binder::bind(*tables.liberated_fn_sigs().get(hir_id).unwrap())?r? @eddyb
Closes: #56132