-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Treat constant values as mir::ConstantKind::Val #94059
Treat constant values as mir::ConstantKind::Val #94059
Conversation
This comment has been minimized.
This comment has been minimized.
@@ -570,6 +570,9 @@ impl<'tcx> Cx<'tcx> { | |||
|
|||
hir::ExprKind::ConstBlock(ref anon_const) => { | |||
let anon_const_def_id = self.tcx.hir().local_def_id(anon_const.hir_id); | |||
|
|||
// FIXME Do we want to use `from_inline_const` once valtrees |
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 think that function is only used from here? . If so, we can move it onto constantkind and turn inline consts always into mir constants
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.
Yes this is only used from here. But changing from_inline_const
would require some changes in how we process patterns during thir construction. The next PR will be about changing thir to use mir::Constant
instead of ty::Const
, so would also include the change to from_inline_const
. I would prefer to leave this as is in this PR, unless you want this change right now.
b76a6d3
to
a4feb9a
Compare
How can I make the 'inline_into_box_place' test not fail in CI? A new alloc value (the |
- } | ||
- | ||
- bb2: { | ||
+ // + span: $DIR/inline-into-box-place.rs:8:33: 8:43 | ||
+ // + user_ty: UserType(0) | ||
+ // + literal: Const { ty: alloc::raw_vec::RawVec<u32>, val: Value(ByRef { alloc: Allocation { bytes: [4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], relocations: Relocations(SortedMap { data: [] }), init_mask: InitMask { blocks: [65535], len: Size { raw: 16 } }, align: Align { pow2: 3 }, mutability: Not, extra: () }, offset: Size { raw: 0 } }) } | ||
+ // + literal: Const { ty: alloc::raw_vec::RawVec<u32>, val: Unevaluated(Unevaluated { def: WithOptConstParam { did: DefId(5:77 ~ alloc[bd09]::raw_vec::{impl#0}::NEW), const_param_did: None }, substs: [u32], promoted: None }) } |
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.
Oof, yea that id is annoying. We should probably make the printing of unevaluted consts work in a more user-facing way. cc @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.
Afaict the issue here is that Debug
for Unevaluated
uses Debug
for DefId
which uses def_path_debug_str
which prints the stable_crate_id
. This ID is presumably not stable between targets so different CI runners disagree about what that ID should be.
It seems like - before this PR - all Unevaluated
constants only referred to the currently compiled crate. The stabile_crate_id
of which is probably stable for different targets.
Writing a potential fix rn.
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 ID is presumably not stable between targets so different CI runners disagree about what that ID should be.
Indeed. Liballoc is compiled by cargo which afaik hashes the target into the value passed in using -Cmetadata
. The -Cmetadata
argumemts are one of the inputs to the stable crate id calculation.
constant.try_super_fold_with(self) | ||
let constant_kind = match constant { | ||
mir::ConstantKind::Ty(c) => { | ||
let const_folded = c.try_super_fold_with(self)?; |
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 seems wrong, we should still normalize constants here, for now this should probably be
let const_folded = c.try_super_fold_with(self)?; | |
let const_folded = c.try_fold_with(self)?; |
but with valtrees we have to avoid the conversion to valtrees here.
If you change this you should be able to avoid the CI issues for now
change `mir::Constant` in mir dumps this removes duplicate information and avoids printing the `stable_crate_id` in mir dumps which broke CI in rust-lang#94059 r? `@oli-obk` cc `@b-naber`
☔ The latest upstream changes (presumably #94209) made this pull request unmergeable. Please resolve the merge conflicts. |
a4feb9a
to
b6608af
Compare
This comment has been minimized.
This comment has been minimized.
b6608af
to
0a82066
Compare
0d58cd0
to
2fa5ed2
Compare
@@ -16,6 +16,7 @@ | |||
|
|||
#![allow(unconditional_panic)] | |||
|
|||
|
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.
@@ -25,10 +25,12 @@ | |||
_3 = &_4; // scope 0 at $DIR/issue-78442.rs:11:5: 11:15 | |||
StorageLive(_5); // scope 0 at $DIR/issue-78442.rs:11:5: 11:17 | |||
nop; // scope 0 at $DIR/issue-78442.rs:11:5: 11:17 | |||
_2 = <impl Fn() as Fn<()>>::call(move _3, move _5) -> [return: bb2, unwind: bb4]; // scope 0 at $DIR/issue-78442.rs:11:5: 11:17 | |||
- _2 = <impl Fn() as Fn<()>>::call(move _3, move _5) -> [return: bb2, unwind: bb4]; // scope 0 at $DIR/issue-78442.rs:11:5: 11:17 | |||
+ _2 = <fn() {foo} as Fn<()>>::call(move _3, move _5) -> [return: bb2, unwind: bb4]; // scope 0 at $DIR/issue-78442.rs:11:5: 11:17 |
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.
bit surprised that this changed with your pr 🤔 but as its definitely a positive change, i don't necessarily care about why this changed 🤷
one last nit, then r=me |
@bors delegate+ |
✌️ @b-naber can now approve this pull request |
2fa5ed2
to
18bb2dd
Compare
📌 Commit 021c3b0 has been approved by |
⌛ Testing commit 021c3b0 with merge 519de42530b84c9cfbd03e9a0354724ba4ab2a5f... |
💔 Test failed - checks-actions |
@bors retry |
The job Click to see the possible cause of the failure (guessed by this bot)
|
…tion, r=lcnr Treat constant values as mir::ConstantKind::Val Another step that is necessary for the introduction of Valtrees: we don't want to treat `ty::Const` instances of kind `ty::ConstKind::Value` as `mir::ConstantKind::Ty` anymore. r? `@oli-obk`
☀️ Test successful - checks-actions |
Finished benchmarking commit (d7b282b): comparison url. Summary: This benchmark run shows 92 relevant improvements 🎉 but 6 relevant regressions 😿 to instruction counts.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression |
|
Since the regressions are all in secondary benchmarks and relatively small, I think it's fine if we consider this to be an improvement rather than a mixed result. @rustbot label: +perf-regression-triaged |
…li-obk Use mir constant in thir instead of ty::Const This is blocked on rust-lang#94059 (does include its changes, the first two commits in this PR correspond to those changes) and rust-lang#93800 being reinstated (which had to be reverted). Mainly opening since `@lcnr` offered to give some feedback and maybe also for a perf-run (if necessary). This currently contains a lot of duplication since some of the logic of `ty::Const` had to be copied to `mir::ConstantKind`, but with the introduction of valtrees a lot of that functionality will disappear from `ty::Const`. Only the last commit contains changes that need to be reviewed here. Did leave some `FIXME` comments regarding future implementation decisions and some things that might be incorrectly implemented. r? `@oli-obk`
Use mir constant in thir instead of ty::Const This is blocked on rust-lang/rust#94059 (does include its changes, the first two commits in this PR correspond to those changes) and rust-lang/rust#93800 being reinstated (which had to be reverted). Mainly opening since `@lcnr` offered to give some feedback and maybe also for a perf-run (if necessary). This currently contains a lot of duplication since some of the logic of `ty::Const` had to be copied to `mir::ConstantKind`, but with the introduction of valtrees a lot of that functionality will disappear from `ty::Const`. Only the last commit contains changes that need to be reviewed here. Did leave some `FIXME` comments regarding future implementation decisions and some things that might be incorrectly implemented. r? `@oli-obk`
Another step that is necessary for the introduction of Valtrees: we don't want to treat
ty::Const
instances of kindty::ConstKind::Value
asmir::ConstantKind::Ty
anymore.r? @oli-obk