-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Do not ICE when combining unsized locals and async #64527
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
8a5f477
to
1d7e3f8
Compare
} | ||
} | ||
} | ||
} | ||
Err(LayoutError::Unsized(_ty)) => { |
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.
We could add an if ty.is_generator()
here, which would ensure the correct error is emitted, and just ICE in any other (in theory unreachable) case.
1d7e3f8
to
a7f375a
Compare
} | ||
} | ||
} | ||
} | ||
Err(LayoutError::Unsized(_ty)) => { | ||
let sp = statement.source_info.span; // async fn block | ||
self.tcx.sess.struct_span_err( |
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.
Uhm; const_prop
is too my knowledge an optimization transform not necessary for correctness so why are we emitting an error here?
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.
Yea I think it's totally fine to just keep doing what the old code did and ignore errors. They may be occuring because we're in a generic function and may be bogus for specific concrete types
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.
Should we close this PR then?
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.
Well; we cannot merge this PR as-is I think but maybe we can morph the PR into something else. You can always open a new one tho... up to you. :)
The job 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 |
@@ -137,6 +137,7 @@ impl<'tcx> ConstEvalErr<'tcx> { | |||
) -> Result<DiagnosticBuilder<'tcx>, ErrorHandled> { | |||
let must_error = match self.error { | |||
err_inval!(Layout(LayoutError::Unknown(_))) | | |||
err_inval!(Layout(LayoutError::Unsized(_))) | |
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.
An unsized type isnt generic, so returning TooGeneric doesnt make sense.
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.
But that's also why this entire approach looks odd... a generic type will eventually be monomorphized, so that's a program that cannot be executed now but can be executed later. But if the type is unsized now it will always be unsized, right, so why does it make any sense to delay the error?
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.
yea that should just be reported via the machinery below, which should simplify the rest
☔ The latest upstream changes (presumably #64419) made this pull request unmergeable. Please resolve the merge conflicts. |
Ping from triage |
Pinging again from triage |
This hasn't seen any movement for some time so I'm going to close it out as inactive. |
Fix #61335.