@bors try @rust-timer queue

this might actually impact perf, if unlikely

Awaiting bors try build completion.

@rustbot label: S-waiting-on-perf

⌛ Trying commit 18e0d916581dc54ddd13e1643d25c81408ad1987 with merge 67ad21cde5ced3782151744e37f78e23af0e8b24...

☀️ Try build successful - checks-actions
Build commit: 67ad21cde5ced3782151744e37f78e23af0e8b24 (67ad21cde5ced3782151744e37f78e23af0e8b24)

Queued 67ad21cde5ced3782151744e37f78e23af0e8b24 with parent d017d59, future comparison URL.

Finished benchmarking commit (67ad21cde5ced3782151744e37f78e23af0e8b24): comparison url.

Instruction count

• Primary benchmarks: 😿 relevant regressions found
• Secondary benchmarks: 🎉 relevant improvements found

Max RSS (memory usage)

Cycles

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: S-waiting-on-review -S-waiting-on-perf perf-regression

the way that mostly incr-unchanged is impacted and all perf impacts are really small I think this isn't too relevant.

I consider this a bug fix.

@bors r

📌 Commit 18e0d916581dc54ddd13e1643d25c81408ad1987 has been approved by lcnr

Const-prop does not run in the body of a const/static, does it?
Those items contain promoteds that might fail to evaluate, so it is crucial that we only evaluate those nested constants that are actually needed to compute the const/static initializer. I tried to fix this but too much code out there has such potentially failing promoteds. :( See #80619.

I am fairly sure I added a test for this so it's probably fine, just double-checking. :)

⌛ Testing commit 18e0d916581dc54ddd13e1643d25c81408ad1987 with merge efa8ecf1ad8601a2b9aa8549d40052761450cc9d...

💔 Test failed - checks-actions

@bors retry

@Dylan-DPC this doesn't look spurious. Can you r- this, please?

@bors r-

Triage:
@b-naber can you post the status of this PR?

I don't know why these lints are output on that machine (which seems to be a 64-bit machine):

Future incompatibility report: Future breakage diagnostic:
error: any use of this value will cause an error
  --> /checkout/src/test/ui/consts/const-eval/issue-50814.rs:15:21
   |
LL |     const MAX: u8 = A::MAX   B::MAX;
   |     ----------------^^^^^^^^^^^^^^^-
   |                     |
   |                     attempt to compute `u8::MAX   u8::MAX`, which would overflow
   |
   = note: `#[deny(const_err)]` on by default
   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
   = note: for more information, see issue #71800 <https://github.com/rust-lang/rust/issues/71800>

Future breakage diagnostic:
error: any use of this value will cause an error
  --> /checkout/src/test/ui/consts/const-eval/issue-50814.rs:15:21
   |
LL |     const MAX: u8 = A::MAX   B::MAX;
   |     ----------------^^^^^^^^^^^^^^^-
   |                     |
   |                     attempt to compute `u8::MAX   u8::MAX`, which would overflow
   |
   = note: `#[deny(const_err)]` on by default
   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
   = note: for more information, see issue #71800 <https://github.com/rust-lang/rust/issues/71800>

This looks like a miri-related lint, @RalfJung do you have any idea why we get those lints on that machine, but not on the ones in the PR CI?

Maybe different flags? Debug vs release mode can make a difference.
Also the lints are emitted by const-prop-lint, which uses Miri but then also does a lot of other stuff, and I'm not much involved with that. Maybe @oli-obk knows more.

Also make sure you rebase, there have been some changes wrt binop overflow checking a few weeks ago.

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

The job x86_64-gnu-llvm-12 failed! Check out the build log: (web) (plain)

---- [mir-opt] src/test/mir-opt/remove-never-const.rs stdout ----

error: compilation failed!
status: exit status: 1
command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/src/test/mir-opt/remove-never-const.rs" "-Zthreads=1" "--target=x86_64-unknown-linux-gnu" "-O" "-Copt-level=1" "-Zdump-mir=all" "-Zvalidate-mir" "-Zdump-mir-exclude-pass-number" "-Zmir-pretty-relative-line-numbers=yes" "-Zmir-opt-level=4" "-Zdump-mir-dir=/checkout/obj/build/x86_64-unknown-linux-gnu/test/mir-opt/remove-never-const" "-C" "prefer-dynamic" "--out-dir" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/mir-opt/remove-never-const" "-Crpath" "-Cdebuginfo=0" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--emit" "mir,link" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/mir-opt/remove-never-const/auxiliary"
stdout: none
--- stderr -------------------------------
  --> /checkout/src/test/mir-opt/remove-never-const.rs:11:8
   |
   |
11 | struct PrintName<T>(T);
   |
   = note: `#[warn(dead_code)]` on by default

warning: function `no_codegen` is never used
warning: function `no_codegen` is never used
  --> /checkout/src/test/mir-opt/remove-never-const.rs:18:4
   |
18 | fn no_codegen<T>() {

warning: associated constant `VOID` is never used
  --> /checkout/src/test/mir-opt/remove-never-const.rs:14:11
   |

The error we get in the failing mir-opt test looks wrong.

I guess the failing mir opt test shows that we fail to add some constants to https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Body.html#structfield.required_consts though I don't know why, how or where.

Promoteds don't get added there. That is by design since their evaluation cannot fail (in fn), or must only be attempted if they are in live code (in const/static).

Not sure if that's the issue here, though.

☔ The latest upstream changes (presumably #101152) made this pull request unmergeable. Please resolve the merge conflicts.

I'm going to close this, not familiar enough with const prop to tell what's really going on here.