-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement the new desugaring from try_trait_v2
#84767
Conversation
| --- consider giving `fut` the explicit type `impl Future`, where the type parameter `E` is specified | ||
... | ||
LL | Ok(()) | ||
| ^^ cannot infer type for type parameter `E` declared on the enum `Result` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@estebank I got some of the places fixed up, but there are some others like this where I've regressed the diagnostics, losing some of the special ?
notes. If you have any pointers to share on how to get them fixed up, I'd appreciate it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be fair, the existing ?
diagnostic was already incorrect: this seems to imply that the async
block behaves similarly to try
, which it doesn't. We might have to proactively look for ?
expressions in async
block bodies and give a specific error for them, or collect their spans and see if any E0282s happen in the same block as one of them, to treat them explicitly. Don't think these should block landing this, but needs to be addressed before these errors land on stable.
| | ||
LL | / fn option_to_result() -> Result<u64, String> { | ||
LL | | Some(3)?; | ||
| | ^ use `.ok_or(...)?` to provide an error compatible with `Result<u64, String>` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❤️ rustc_on_unimplemented
c65047a
to
1f5d2ee
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit b1cf4cec0ab0c51b45db9c665ade7419c7cd85f0 with merge 9e1fbcd2d92fbe606de781106bb28b5c1e981c0a... |
☀️ Try build successful - checks-actions |
Queued 9e1fbcd2d92fbe606de781106bb28b5c1e981c0a with parent 59f551a, future comparison URL. |
Finished benchmarking try commit (9e1fbcd2d92fbe606de781106bb28b5c1e981c0a): comparison url. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up. @bors rollup=never |
try_trait_v2
try_trait_v2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nits, then r=me
@bors rollup=never |
Thanks for the suggestions, lcnr! Co-authored-by: lcnr <[email protected]>
This comment has been minimized.
This comment has been minimized.
@bors r=lcnr |
📌 Commit e2edee4 has been approved by |
☀️ Test successful - checks-actions |
Tested on commit rust-lang/rust@4e3e6db. Direct link to PR: <rust-lang/rust#84767> 💔 rls on windows: test-pass → build-fail (cc @Xanewok). 💔 rls on linux: test-pass → build-fail (cc @Xanewok).
Implement the new desugaring from `try_trait_v2` ~~Currently blocked on rust-lang#84782, which has a PR in rust-lang#84811 Rebased atop that fix. `try_trait_v2` tracking issue: rust-lang#84277 Unfortunately this is already touching a ton of things, so if you have suggestions for good ways to split it up, I'd be happy to hear them. (The combination between the use in the library, the compiler changes, the corresponding diagnostic differences, even MIR tests mean that I don't really have a great plan for it other than trying to have decently-readable commits. r? `@ghost` ~~(This probably shouldn't go in during the last week before the fork anyway.)~~ Fork happened.
@lcnr @scottmcm this looks like it caused some bigger perf issues after merging than in the original perf run. A cursory look points to |
There's actually less MIR being produced now. The red at https://github.com/rust-lang/rust/pull/84767/files#diff-d93592ecc730e2061ac31cad11e78e3bb7cdc7ca3257a85f04bbd3f48c0c6521L1938 is because it only needs to make one call ( My guess would be more stress on the type solvers. jyn pointed out that diesel is hitting |
Currently blocked on #84782, which has a PR in #84811Rebased atop that fix.try_trait_v2
tracking issue: #84277Unfortunately this is already touching a ton of things, so if you have suggestions for good ways to split it up, I'd be happy to hear them. (The combination between the use in the library, the compiler changes, the corresponding diagnostic differences, even MIR tests mean that I don't really have a great plan for it other than trying to have decently-readable commits.
r? @ghost
(This probably shouldn't go in during the last week before the fork anyway.)Fork happened.