-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Remove DefiningAnchor::Bubble
from MIR validation
#116803
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
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -15,6 +15,7 @@ use rustc_trait_selection::traits::ObligationCtxt; | |
pub fn is_equal_up_to_subtyping<'tcx>( | ||
tcx: TyCtxt<'tcx>, | ||
param_env: ParamEnv<'tcx>, | ||
anchor: DefiningAnchor, | ||
src: Ty<'tcx>, | ||
dest: Ty<'tcx>, | ||
) -> bool { | ||
|
@@ -24,8 +25,8 @@ pub fn is_equal_up_to_subtyping<'tcx>( | |
} | ||
|
||
// Check for subtyping in either direction. | ||
relate_types(tcx, param_env, Variance::Covariant, src, dest) | ||
|| relate_types(tcx, param_env, Variance::Covariant, dest, src) | ||
relate_types(tcx, param_env, anchor, Variance::Covariant, src, dest) | ||
|| relate_types(tcx, param_env, anchor, Variance::Covariant, dest, src) | ||
} | ||
|
||
/// Returns whether `src` is a subtype of `dest`, i.e. `src <: dest`. | ||
|
@@ -39,6 +40,7 @@ pub fn is_equal_up_to_subtyping<'tcx>( | |
pub fn relate_types<'tcx>( | ||
tcx: TyCtxt<'tcx>, | ||
param_env: ParamEnv<'tcx>, | ||
anchor: DefiningAnchor, | ||
variance: Variance, | ||
src: Ty<'tcx>, | ||
dest: Ty<'tcx>, | ||
|
@@ -47,8 +49,7 @@ pub fn relate_types<'tcx>( | |
return true; | ||
} | ||
|
||
let mut builder = | ||
tcx.infer_ctxt().ignoring_regions().with_opaque_type_inference(DefiningAnchor::Bubble); | ||
let mut builder = tcx.infer_ctxt().ignoring_regions().with_opaque_type_inference(anchor); | ||
let infcx = builder.build(); | ||
let ocx = ObligationCtxt::new(&infcx); | ||
let cause = ObligationCause::dummy(); | ||
|
@@ -59,19 +60,23 @@ pub fn relate_types<'tcx>( | |
Err(_) => return false, | ||
}; | ||
let errors = ocx.select_all_or_error(); | ||
// With `Reveal::All`, opaque types get normalized away, with `Reveal::UserFacing` | ||
// we would get unification errors because we're unable to look into opaque types, | ||
// even if they're constrained in our current function. | ||
for (key, ty) in infcx.take_opaque_types() { | ||
let hidden_ty = tcx.type_of(key.def_id).instantiate(tcx, key.args); | ||
if hidden_ty != ty.hidden_type.ty { | ||
span_bug!( | ||
ty.hidden_type.span, | ||
"{}, {}", | ||
tcx.type_of(key.def_id).instantiate(tcx, key.args), | ||
ty.hidden_type.ty | ||
); | ||
|
||
if anchor != DefiningAnchor::Error { | ||
// With `Reveal::All`, opaque types get normalized away, with `Reveal::UserFacing` | ||
Comment on lines
+64
to
+65
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The relationship between what the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Well I didn't touch that comment, but I'll rework it I guess. |
||
// we would get unification errors because we're unable to look into opaque types, | ||
// even if they're constrained in our current function. | ||
for (key, ty) in infcx.take_opaque_types() { | ||
let hidden_ty = tcx.type_of(key.def_id).instantiate(tcx, key.args); | ||
if hidden_ty != ty.hidden_type.ty { | ||
span_bug!( | ||
ty.hidden_type.span, | ||
"{}, {}", | ||
tcx.type_of(key.def_id).instantiate(tcx, key.args), | ||
ty.hidden_type.ty | ||
); | ||
} | ||
} | ||
} | ||
|
||
errors.is_empty() | ||
} |
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.
CTFE is always performed with a
Reveal::All
param-env (or it should, as far as I'm aware?) so it makes sense to useDefiningAnchor::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.
I don't think that's true? We run CTFE for const generics as well and the param-env is different there.
Cc @oli-obk @lcnr
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.
My justification is wrong here. We're not using a
Reveal::All
param-env, but we have passed this body through theRevealAll
mir-pass.Not totally clear if that's sufficient, but if it isn't, then we don't have a test 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.
We can also approximate the defining anchor from the current stack frame. See newest commit for approach.
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.
This is a bit of a mess. We re-use the result from running with
Reveal::UserFacing
when running withReveal::All
in CTFE. However, afaik there is (and well... should be) no call site actually usingReveal::UserFacing
. I think we should switch to always useReveal::All
:Reveal::UserFacing
after revealing opaque types can result in weird errors and failures, as we end up trying to relate an opaque and its revealed (but normally hidden) typeconst
-function returningimpl Iterator<Item = u32>
they actually want to be able to use the returned value as an iterator. The check that we only treat the type opaquely happened in typeck but during codegen this behavior is undesirable. I haven't thought about specialization and default associated types yet, but also, idc. cc Stop usingReveal::All
before borrowck #101478 where I tried to change const generics CTFE to useReveal::UserFacing
.