-
Notifications
You must be signed in to change notification settings - Fork 13k
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
regression: ICE failed to get output type of async function #123273
Comments
could be related to #105304 but may also be a red herring 🐟 🤔 |
Regression in rust-lang-ci@cb682d3 searched nightlies: from nightly-2024-01-01 to nightly-2024-03-18 bisected with cargo-bisect-rustc v0.6.8Host triple: x86_64-unknown-linux-gnu cargo bisect-rustc --start=2024-01-01 --end=2024-03-18 --regress=ice |
Seems like a quick diagnostics fix-forward. I'll put up a PR in a few hours when I'm done bisecting more PRs. @rustbot claim |
WG-prioritization assigning priority (Zulip discussion). @rustbot label -I-prioritize +P-high |
…youxu Stop using `HirId` for fn-like parents since closures are not `OwnerNode`s This is a minimal fix for rust-lang#123273. I'm overall pretty disappointed w/ the state of this code; although it's "just diagnostics", it still should be maintainable and understandable and neither of those are true. I believe this code really needs some major overhauling before anything more should be added to it, because there are subtle invariants that are being exercised and subsequently broken all over the place, and I don't think we should just paper over them (e.g.) by delaying bugs or things like that. I wouldn't be surprised if fixing up this code would also yield better diagnostics.
Rollup merge of rust-lang#123804 - compiler-errors:podcrab-fix, r=jieyouxu Stop using `HirId` for fn-like parents since closures are not `OwnerNode`s This is a minimal fix for rust-lang#123273. I'm overall pretty disappointed w/ the state of this code; although it's "just diagnostics", it still should be maintainable and understandable and neither of those are true. I believe this code really needs some major overhauling before anything more should be added to it, because there are subtle invariants that are being exercised and subsequently broken all over the place, and I don't think we should just paper over them (e.g.) by delaying bugs or things like that. I wouldn't be surprised if fixing up this code would also yield better diagnostics.
The text was updated successfully, but these errors were encountered: