-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
refactor check_{lang,library}_ub: use a single intrinsic #122629
Changes from all commits
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 |
---|---|---|
|
@@ -621,7 +621,7 @@ impl Rvalue { | |
Rvalue::NullaryOp(NullOp::SizeOf | NullOp::AlignOf | NullOp::OffsetOf(..), _) => { | ||
Ok(Ty::usize_ty()) | ||
} | ||
Rvalue::NullaryOp(NullOp::UbCheck(_), _) => Ok(Ty::bool_ty()), | ||
Rvalue::NullaryOp(NullOp::UbChecks, _) => Ok(Ty::bool_ty()), | ||
Rvalue::Aggregate(ak, ops) => match *ak { | ||
AggregateKind::Array(ty) => Ty::try_new_array(ty, ops.len() as u64), | ||
AggregateKind::Tuple => Ok(Ty::new_tuple( | ||
|
@@ -989,13 +989,7 @@ pub enum NullOp { | |
/// Returns the offset of a field. | ||
OffsetOf(Vec<(VariantIdx, FieldIdx)>), | ||
/// cfg!(debug_assertions), but at codegen time | ||
UbCheck(UbKind), | ||
} | ||
|
||
#[derive(Clone, Debug, Eq, PartialEq)] | ||
pub enum UbKind { | ||
LanguageUb, | ||
LibraryUb, | ||
UbChecks, | ||
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. I see no choice but to change smir here; the things it exposed were never meant to be very stable to begin with and I don't think we want to keep them. 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. I've just been breaking smir every time I change MIR. Is there any guidance or enforcement that we don't do that? 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. No idea. SMIR people get pinged when this happens so I guess they'll complain when it gets too much for them. ;) 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. It would be nice to avoid these breakages. If something is unstable, we recommend to not expose them, or expose as an Opaque type. See Coverage statement as an example. 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. In this specific case, we could just always use the same UbKind value, and mark UbValue as deprecated. 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. If we leave compatibility shims in stable MIR (not that I think we should do that in this PR), is there a plan for how to remove them eventually? 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. StableMIR is not yet versioned, but once it is, we would likely go over things that has been marked as deprecated and remove them when a new major is about to be released. 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. @RalfJung I think it is fine to remove it now. I do have a question about how to evaluate this operator though. Is the idea here that we are assessing the value of Is it possible to document the answer here? 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. Yes, exactly. This is what the existing documentation means when it says "the value of debug_assertions at monomorphization time". 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. I have also extended the intrinsic's docs to make this more clear. |
||
} | ||
|
||
impl Operand { | ||
|
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 see any corresponding changes to the mir-opt tests, which has me worried. CI is green but the mir-opt suite does not pass locally. Do you know what's happening here? I'm confident that this either will fail in bors or should fail in bors, so at the least the mir-opt tests need to be blessed, and maybe we also have a CI/bootstrap bug.
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.
Good point. I think this happens because of
The PR runner has debug assertions turned 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.
Ah yes this old problem. I'll see if I can do a PR to fix 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.
Is that even still needed? The stdlib is less dependent on the sysroot
cfg(debug_assertions)
now with your new intrinsic.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.
There is less need for it, but it's not gone entirely. I'll start by just enabling the tests that can be enabled for free: #122921