Remove confusing 'while checking' note from opaque future type mismatches #107201
Conversation
This file contains hidden or 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
rustbot
added
S-waiting-on-review
This comment has been minimized.
This comment has been minimized.
compiler-errors
force-pushed
the
confusing-async-fn-note
branch
from
c7be912 to
a63f5dc
Compare
|
I'm not entirely convinced that removing the span is an unambiguous improvement, but the current output isn't great either. |
|
@estebank - I agree, but I think the current wording is bordering on actively confusing. I'm open to suggestions for a wording, but getting it to fit into the existing machinery might be hard. |
|
I can't further review this now, but I think r=me. |
|
@bors r=estebank rollup |
|
🌲 The tree is currently closed for pull requests below priority 50. This pull request will be tested once the tree is reopened. |
bors
added
S-waiting-on-bors
compiler-errors
added a commit
to compiler-errors/rust
that referenced
this pull request
Feb 2, 2023
…-note, r=estebank
Remove confusing 'while checking' note from opaque future type mismatches
Maybe I'm just misinterpreting the wording of the note. The only value I can see in this note is that it points out where the async's opaque future is coming from, but the way it's doing it is misleading IMO.
For example:
```rust
note: while checking the return type of the `async fn`
--> $DIR/dont-suggest-missing-await.rs:7:24
|
LL | async fn make_u32() -> u32 {
| ^^^ checked the `Output` of this `async fn`, found opaque type
```
We point at the type `u32` in the HIR, but then say "found opaque type". We also say "while checking"... but we're typechecking a totally different function when we get this type mismatch!
r? `@estebank` but feel free to reassign and/or take your time reviewing this. I'd be inclined to also discuss reworking the presentation of this type mismatch to restore some of these labels in a way that makes it more clear what it's trying to point out.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 2, 2023
…iaskrgr Rollup of 5 pull requests Successful merges: - rust-lang#107201 (Remove confusing 'while checking' note from opaque future type mismatches) - rust-lang#107312 (Add Style Guide rules for let-else statements) - rust-lang#107488 (Fix syntax in `-Zunpretty-expanded` output for derived `PartialEq`.) - rust-lang#107531 (Inline CSS background images directly into the CSS) - rust-lang#107576 (Add proc-macro boilerplate to crt-static test) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
# for free
to join this conversation on GitHub.
Already have an account?
# 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.
Maybe I'm just misinterpreting the wording of the note. The only value I can see in this note is that it points out where the async's opaque future is coming from, but the way it's doing it is misleading IMO.
For example:
We point at the type
u32in the HIR, but then say "found opaque type". We also say "while checking"... but we're typechecking a totally different function when we get this type mismatch!r? @estebank but feel free to reassign and/or take your time reviewing this. I'd be inclined to also discuss reworking the presentation of this type mismatch to restore some of these labels in a way that makes it more clear what it's trying to point out.