-
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
correctly deal with user type ascriptions in pat #96515
Conversation
This comment has been minimized.
This comment has been minimized.
I don't really understand the PR description, @lcnr :( maybe we can find some time to sync up on this. I'd like to understand better what is going on! |
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.
r=me if you add back in the "inferred type" in the pretty printer and have an open PR against rustc-dev-guide that at least starts to explain wtf is going on here :)
@bors r+ |
📌 Commit 9b5a0f55a7d08ec900a7ca3e08de1e9ef4b634fa has been approved by |
⌛ Testing commit 9b5a0f55a7d08ec900a7ca3e08de1e9ef4b634fa with merge 35e0e69c59029e2659cc6b35c3d1006856e44995... |
This comment has been minimized.
This comment has been minimized.
💔 Test failed - checks-actions |
@bors r=nikomatsakis |
📌 Commit 7637008 has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (e52e711): comparison url. Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results
CyclesResults
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression Footnotes |
supersedes #93856
thir::PatKind::AscribeUserType
previously resulted inCanonicalUserTypeAnnotations
where the inferred type already had a subtyping relation according tovariance
to theuser_ty
.The bug can pretty much be summarized as follows:
user_ty -> inferred_ty
: considers varianceStatementKind::AscribeUserType
:inferred_ty
is the type of the place, so no variance neededuser_ty -> inferred_ty
: does not consider varianceStatementKind::AscribeUserType
: applies varianceThis mostly worked fine. The lifetimes in
inferred_ty
were only bound by its relation touser_ty
and to theplace
ofStatementKind::AscribeUserType
, so it doesn't matter where exactly the subtyping happens.It does however matter when having higher ranked subtying. At this point the place where the subtyping happens is forced, causing this mismatch between building and borrowck to result in unintended errors.
cc #96514 which is pretty much the same issue
r? @nikomatsakis