-
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
Fix for reverted PR #103880 #105958
Fix for reverted PR #103880 #105958
Conversation
This PR changes MIR cc @oli-obk, @RalfJung, @JakobDegen, @davidtwco, @celinval, @vakaras |
Let's make sure we run perf on this before merging and decide whether the regression seen on #103880 (comment) is justified. |
Yes, also saw that. We did run perf twice on the previous PR though. Can you start a perf run? |
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
⌛ Trying commit 2bd63fc with merge 3be3d9020c6273426964e1caf1859956d1e6d2fd... |
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
I didn't see -- perhaps I missed it -- a comment explaining the performance regression. That's something we hope/expect PR authors/reviewers to write up prior to merging a PR with known regressions. |
Finished benchmarking commit (3be3d9020c6273426964e1caf1859956d1e6d2fd): comparison URL. Overall result: ❌ regressions - ACTION NEEDEDBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
|
@@ -109,7 +109,7 @@ impl<'pat, 'tcx> MatchPair<'pat, 'tcx> { | |||
let may_need_cast = match place { | |||
PlaceBuilder::Local { local, ref projection } => { | |||
let ty = Place::ty_from(local, projection, &cx.local_decls, cx.tcx).ty; | |||
ty != pattern.ty && ty.has_opaque_types() | |||
ty.has_opaque_types() && !pattern.ty.has_opaque_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.
i fear that this may only make the bug harder to trigger rather than actually fixing it.
You could imagine having a field like (subtype, opaque)
to (supertype, opaque)
which hits both the old and the new check.
What is the exact reason that we get an ICE there? Is the issue subtyping in OpaqueCast
or something else?
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.
hm I'm not sure, the comment above l.109
states Only add the OpaqueCast projection if the given place is an opaque type and the expected type from the pattern is not.
I don't know how OpaqueCast
s are handled later or why we need them (they're only used for opaque types, aren't they?). Would we really need an OpaqueCast
only because of the subtype/suptype
here?
I think the ICE is triggered because the type in the OpaqueCast
is still generic in codegen and we therefore cannot get a layout for 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.
ah (subtype, opaque)
to (supertype, opaque)
doesn't trigger this with your fix.
still worried about (subtype, opaque)
to (supertype, concrete)
.
I think the ICE is triggered because the type in the
OpaqueCast
is still generic in codegen and we therefore cannot get a layout for it.
This doesn't make sense to me. OpaqueCast
should never be generic during codegen. We should substitute the concrete generic arguments during codegen if the OpaqueCast
projection still exist there. An alternative might be that we're missing a normalization for the opaque cast but that also seems weird 🤔
Use covariance on type relations of field projection types if possible It's fine to use covariance here unless we're in a mutating context. Fixes rust-lang#96514 Supersedes rust-lang#105958 r? `@lcnr`
Closed in favor of #107969 |
Use covariance on type relations of field projection types if possible It's fine to use covariance here unless we're in a mutating context. Fixes rust-lang/rust#96514 Supersedes rust-lang/rust#105958 r? `@lcnr`
Use covariance on type relations of field projection types if possible It's fine to use covariance here unless we're in a mutating context. Fixes rust-lang/rust#96514 Supersedes rust-lang/rust#105958 r? `@lcnr`
Use covariance on type relations of field projection types if possible It's fine to use covariance here unless we're in a mutating context. Fixes rust-lang/rust#96514 Supersedes rust-lang/rust#105958 r? `@lcnr`
This re-introduces the changes in #103880, which was reverted in #105905.
The bug was caused by an unnecessary
OpaqueCast
, which was inserted because the condition for its introduction was violated by changing the field type.Fixes #105881 (thanks to @trinity-1686a for the mcve)
Fixes #105819
#105905 already introduced a test for #105809
I successfully compiled cbindgen with this fix (#105886), but don't have a mcve for that issue.
r? @lcnr