-
Notifications
You must be signed in to change notification settings - Fork 13.9k
misc coercion cleanups and handle safety correctly #148602
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
Draft
BoxyUwU
wants to merge
6
commits into
rust-lang:master
Choose a base branch
from
BoxyUwU:coercion_cleanup_uncontroversial
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
misc coercion cleanups and handle safety correctly #148602
BoxyUwU
wants to merge
6
commits into
rust-lang:master
from
BoxyUwU:coercion_cleanup_uncontroversial
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- leak checking the lub for fndef<->fndef coerce-lubs - start lubbing closure<->closure coerce-lubs and leak check it
|
The job Click to see the possible cause of the failure (guessed by this bot) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
S-waiting-on-author
Status: This is awaiting some action (such as code changes or more information) from the author.
T-clippy
Relevant to the Clippy team.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
r? lcnr
todo: write better PR description and FCP comment for the safety stuff
"remove normalize call"
Fixes #132765 in theory breaking as we might now treat some previously-ambig hr aliases as rigid when we shouldn't. we may want to explicitly normalize the coercion target in
fcx.coercelike the new solver does."leak check and lub for closure<->closure coerce-lubs of same defids"
Fixes rust-lang/trait-system-refactor-initiative#233
the
|x| x + 1expr has a type ofClosure(?31t)which we wind up inferring the RPIT to. TheCoerceManyret_coercionfor the wholepeculiartypeck has an expected type ofRPIT(unnormalized). When we type check thereturn |x| x + 1expr we go from the never type toClosure(?31t)which then participates in theret_coerciongiving us acoerce-lub(RPIT, Closure(?31t)).Normalizing
RPITgives us someClosure(?50t)where?31tand?50thave been unified with?31tas the root var.resolve_vars_if_possibledoesn't resolve infer vars to their roots so these wind up with different structural identities so the fast path doesn't apply and we fall back to coercing to afnptr. cc #147193 which also fixes thisNew solver probably just gets more inference variables here because canonicalization + generally different approach to normalization of opaques. Idk :3
This technically allows more code to compile (see the test using TAIT in the commit). I don't think this can be observed on stable though.
In theory this could break existing code that relied on coercing a closure to itself resulting in a fnptr. I don't expect this to really happen in practice and this is an "obvious" bug fix.
leak check fndef<->fndef lubs of the same defids
when coerce-lub'ing a fndef with another fndef we already try to
lubit first to avoid coercing to a fnptr unnecessarily. we now leak check after thisluboperation.this avoids us incorrectly considering the fndefs to be equal despite unequal binders and then winding up with borrow checker errors due when coercing to a fnptr would have worked fine. see
tests/ui/coercion/leak_check_fndef_lub.rsthis is theoretically a breaking change as there could be dead code that relied on these unsatisfiable region constraints never being checked while also asserting that the output of the lub operation was an fndef. I don't think such code is likely to exist, and even if it does I am comfortable breaking it in favour of making code start working that expects us to coerce to a fnptr for unequal fndefs.
"account for safe target features in fndef<->closure and fndef<->fndef coerce-lubs"
We previously did not take safe target features into account when creating the fn sig for fndefs during
fndef<->closureorfndef<->fndefcoerce-lubs. We now do allowingcoerce-lubto produce a safe fn pointer when fndefs with safe target features are involved. This is consistent with existing (non lub) coercion logic forfndef->fnptrwhich allows coercing to a safe fn pointer.