Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Cleanup number handling in match exhaustiveness #116281

Merged
merged 4 commits into from
Oct 1, 2023
Merged

Cleanup number handling in match exhaustiveness #116281

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
fac50e8
Evaluate float consts eagerly
Nadrieril Sep 29, 2023
d6e9b32
No need to carry `bias` in `IntRange`
Nadrieril Sep 29, 2023
0a6d794
Cleanup number literal evaluation
Nadrieril Sep 29, 2023
eac7bcd
Move `eval_bits` optimization upstream
Nadrieril Sep 30, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 10 additions & 1 deletion compiler/rustc_middle/src/mir/consts.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -288,7 +288,16 @@ impl<'tcx> Const<'tcx> {
tcx: TyCtxt<'tcx>,
param_env: ty::ParamEnv<'tcx>,
) -> Option<ScalarInt> {
self.try_eval_scalar(tcx, param_env)?.try_to_int().ok()
match self {
// If the constant is already evaluated, we shortcut here.
Const::Ty(c) if let ty::ConstKind::Value(valtree) = c.kind() => {
valtree.try_to_scalar_int()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure this helps? self.eval will return immediately for ty::ConstKind::Value.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I measured a small change on one benchmark yeah. I think looking through the code it always goes through a query

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, there's the valtree_to_const_val. But then we should really have this as a fast-path in try_eval_scalar and it should apply on all Const::Ty, not just for things that are already valtrees.

#116457

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I considered it, but the optimization is only correct if we know the normal path will only find Valtree::Leaf I think. We talked about it here #116281 (comment)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mostly felt out of my depth on this ngl

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Such discussion should definitely have resulted in a comment in the code...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is still a change in behavior. Previously, try_eval_scalar_int would have worked on struct newtypes around integers; now it might return None since those are branch valtrees (under our current representation).

Also, previously if this accidentally got called on a reference it would have returned None, but now when called on &i32 it will return the integer value. That seems bad.

Copy link
Member Author

@Nadrieril Nadrieril Oct 5, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh that's not good at all. I did run all tests once with an assert checking that it's only called on numeric types fwiw. Also there was almost no difference when I loved it into try_eval_scalar_int. We could leave it in deconstruct_pat and document the choices made

Copy link
Member

@RalfJung RalfJung Oct 5, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did run all tests once with an assert checking that it's only called on numeric types fwiw.

That doesn't help guard against new uses introduced tomorrow.

#116457 should fix this.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yeah that's much better

},
// This is a more general form of the previous case.
_ => {
self.try_eval_scalar(tcx, param_env)?.try_to_int().ok()
},
}
}

#[inline]
Expand Down
Loading
Loading