make const_err a future incompat lint

[RalfJung]

This is the first step for #71800: make const_err a future-incompat lint. I also rewrote the const_err lint description as the old one seemed wrong.

This has the unfortunate side-effect of making const-eval error even more verbose by making the const_err message longer without fixing the redundancy caused by additionally emitting an error on each use site of the constant. We cannot fix that redundancy until const_err is a hard error (at that point the error-on-use-site can be turned into a delay_span_bug! for uses of monomorphic consts, and into a nicely rendered error for [lazily / post-monomorhization evaluated] associated consts).

The one annoying effect of this PR is that let _x = &(1/(1-1)); now also shows the future-incompat warning, even though of course we will not make this a hard error. We'll instead (hopefully) stop promoting it -- see rust-lang/rfcs#3027. The only way I see to avoid the future-incompat warning is to use a different lint for "failure to evaluate promoted".

Cc @rust-lang/wg-const-eval

[rust-highfive]

r? @estebank

(rust-highfive has picked a reviewer for you, use r? to override)

[rust-log-analyzer]

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

Click to see the possible cause of the failure (guessed by this bot)

.................................................................................................... 9000/11200
.................................................................................................... 9100/11200
..........................................................................................i......i.. 9200/11200
.................................................................................................... 9300/11200
.............................iiiiii..iiiiii.i....................................................... 9400/11200
.................................................................................................... 9600/11200
.................................................................................................... 9700/11200
.................................................................................................... 9800/11200
.................................................................................................... 9900/11200
---

---- [ui] ui/error-codes/E0396-fixed.rs stdout ----
diff of stderr:

7    |                            unable to turn bytes into a pointer
8    |
9    = note: `#[deny(const_err)]` on by default
+    = note: for more information, see issue #71800 <https://github.com/rust-lang/rust/issues/71800>
10 
11 error: aborting due to previous error
12 
12 


The actual stderr differed from the expected stderr.
Actual stderr saved to /checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/error-codes/E0396-fixed/E0396-fixed.stderr
To update references, rerun the tests and pass the `--bless` flag
To only update this specific test, also pass `--test-args error-codes/E0396-fixed.rs`
error: 1 errors occurred comparing output.
status: exit code: 1
status: exit code: 1
command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/src/test/ui/error-codes/E0396-fixed.rs" "-Zthreads=1" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Zemit-future-incompat-report" "--emit" "metadata" "-C" "prefer-dynamic" "--out-dir" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/error-codes/E0396-fixed" "-A" "unused" "-Crpath" "-O" "-Cdebuginfo=0" "-Zunstable-options" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/error-codes/E0396-fixed/auxiliary"
------------------------------------------

------------------------------------------
stderr:
stderr:
------------------------------------------
error: any use of this value will cause an error
   |
   |
LL | const VALUE: u8 = unsafe { *REG_ADDR };
   |                            |
   |                            |
   |                            unable to turn bytes into a pointer
   |
   = note: `#[deny(const_err)]` on by default
   = note: for more information, see issue #71800 <https://github.com/rust-lang/rust/issues/71800>

error: aborting due to previous error

---

Some tests failed in compiletest suite=ui mode=ui host=x86_64-unknown-linux-gnu target=x86_64-unknown-linux-gnu


command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" "--compile-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib" "--run-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "--rustc-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--src-base" "/checkout/src/test/ui" "--build-base" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui" "--stage-id" "stage2-x86_64-unknown-linux-gnu" "--suite" "ui" "--mode" "ui" "--target" "x86_64-unknown-linux-gnu" "--host" "x86_64-unknown-linux-gnu" "--llvm-filecheck" "/usr/lib/llvm-9/bin/FileCheck" "--nodejs" "/usr/bin/node" "--host-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--target-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--docck-python" "/usr/bin/python2.7" "--lldb-python" "/usr/bin/python2.7" "--gdb" "/usr/bin/gdb" "--quiet" "--llvm-version" "9.0.0" "--llvm-components" "aarch64 aarch64asmparser aarch64codegen aarch64desc aarch64disassembler aarch64info aarch64utils aggressiveinstcombine all all-targets amdgpu amdgpuasmparser amdgpucodegen amdgpudesc amdgpudisassembler amdgpuinfo amdgpuutils analysis arm armasmparser armcodegen armdesc armdisassembler arminfo armutils asmparser asmprinter avr avrasmparser avrcodegen avrdesc avrdisassembler avrinfo binaryformat bitreader bitstreamreader bitwriter bpf bpfasmparser bpfcodegen bpfdesc bpfdisassembler bpfinfo codegen core coroutines coverage debuginfocodeview debuginfodwarf debuginfogsym debuginfomsf debuginfopdb demangle dlltooldriver engine executionengine fuzzmutate globalisel hexagon hexagonasmparser hexagoncodegen hexagondesc hexagondisassembler hexagoninfo instcombine instrumentation interpreter ipo irreader jitlink lanai lanaiasmparser lanaicodegen lanaidesc lanaidisassembler lanaiinfo libdriver lineeditor linker lto mc mca mcdisassembler mcjit mcparser mips mipsasmparser mipscodegen mipsdesc mipsdisassembler mipsinfo mirparser msp430 msp430asmparser msp430codegen msp430desc msp430disassembler msp430info native nativecodegen nvptx nvptxcodegen nvptxdesc nvptxinfo objcarcopts object objectyaml option orcjit passes perfjitevents powerpc powerpcasmparser powerpccodegen powerpcdesc powerpcdisassembler powerpcinfo profiledata remarks riscv riscvasmparser riscvcodegen riscvdesc riscvdisassembler riscvinfo riscvutils runtimedyld scalaropts selectiondag sparc sparcasmparser sparccodegen sparcdesc sparcdisassembler sparcinfo support symbolize systemz systemzasmparser systemzcodegen systemzdesc systemzdisassembler systemzinfo tablegen target textapi transformutils vectorize webassembly webassemblyasmparser webassemblycodegen webassemblydesc webassemblydisassembler webassemblyinfo windowsmanifest x86 x86asmparser x86codegen x86desc x86disassembler x86info x86utils xcore xcorecodegen xcoredesc xcoredisassembler xcoreinfo xray" "--system-llvm" "--cc" "" "--cxx" "" "--cflags" "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" "--android-cross-path" "" "--color" "always"


failed to run: /checkout/obj/build/bootstrap/debug/bootstrap --stage 2 test --exclude src/tools/tidy
Build completed unsuccessfully in 0:15:59

[ehuss]

@RalfJung Can you say more why the old documentation was wrong? I was trying to distill RFC 1229 into a few short sentences, and I thought it captured the essence that this lint exists to handle backwards compatibility for new checks and errors added to the const evaluator (particularly for non-const contexts). The example code was also written to try to emphasize that fact.

Can you also include a link in the docs for the future-incompat issue? It is not added automatically in the documentation, so you have to add something like See [issue #71800](https://github.com/rust-lang/rust/issues/71800) for more details..

[oli-obk]

The only way I see to avoid the future-incompat warning is to use a different lint for "failure to evaluate promoted".

That seems like the right way forward, but I'm ok with erroneously mentioning that we're going to hard error this in the future even if we know we won't

[RalfJung]

Can you say more why the old documentation was wrong? I was trying to distill RFC 1229 into a few short sentences, and I thought it captured the essence that this lint exists to handle backwards compatibility for new checks and errors added to the const evaluator (particularly for non-const contexts). The example code was also written to try to emphasize that fact.

The thing is, the const_err lint wasn't about anything related to backwards compatibility -- not since unconditional_panic and arithmetic_overflow have been moved to their own lints. const_err is about errors occurring when evaluating a const that wasn't used -- for const that are used, there's no choice but raise a hard error when there is an evaluation error.

The confusing bit here is related to what I said above about &(1/(1-1)): promotion turns this into a constant that fails to evaluate, so this also raises const_err. But IMO the fix here is to stop promoting this, see rust-lang/rfcs#3027.

Can you also include a link in the docs for the future-incompat issue? It is not added automatically in the documentation, so you have to add something like See issue #71800 for more details..

Thanks, will do.

[bors]

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

[RalfJung]

The only way I see to avoid the future-incompat warning is to use a different lint for "failure to evaluate promoted".

That seems like the right way forward, but I'm ok with erroneously mentioning that we're going to hard error this in the future even if we know we won't

Alternatively, these errors should disappear when/if #80579 lands.

[RalfJung]

Nominating for lang team discussion to get signoff on the plan to make const_err a future-incompat lint (and eventually a hard error). See #71800 for some prior discussion.

Cc @rust-lang/lang

[Mark-Simulacrum]

We discussed this in today's lang team meeting, and wanted to write up a comment and then discuss again so that we could better understand the trajectory and overall context here.

I've re-read the associated tracking issue (#71800), and I want to first summarize what const_err is about: const_err lints on entirely unused consts, intending to help crate authors who declare consts which could not be referenced by downstream code; it has no impact on generated code as these constants are already a hard error to use.

This PR implements the first step towards making failure to evaluate a const a hard error in the compiler by moving this lint to a future compatible lint (it is already deny-by-default). The expected impact is low, as the majority of crates do not allow this lint (since declaring a constant that errors on evaluation, but not wanting compilation to stop, is quite odd).

This PR, when originally written, has some undesirable error message implications due to touching on promoted consts which end up unused, but once #80579 lands, that will not be the case; T-lang also discussed that PR today and came to the conclusion that we would like to merge it so it is no longer a concern here.

@RalfJung - does this comment sound accurate? If so, I would expect lang to just approve this next week; I do not think an FCP is needed as future incompatibility is not committing us to anything.

[RalfJung]

const_err lints on entirely unused consts, intending to help crate authors who declare consts which could not be referenced by downstream code; it has no impact on generated code as these constants are already a hard error to use.

Well... not entirely. const_err lints on all consts that fail to evaluate in their CTFE query. For consts that are actually used somewhere, we additionally emit a brief hard error "use of invalid const" (and there is no choice here, we cannot compile this code). We have to emit this hard error in case the user did allow(const_err).

Naively, entirely unused consts would never even have their query fired, but to make sure the user is aware of possible issues with unused consts, there is a lint pass which simply triggers the CTFE query for all consts, used or not. This ensures even unused consts have the lint emitted -- they do not get the hard error though.

The goal is that once const_err is a hard error, we can adjust the code where consts are used to not emit another error/lint, but to simply bug! or delay_span_bug as appropriate. This will also solve issues like #65597.

This PR implements the first step towards making failure to evaluate a const a hard error in the compiler by moving this lint to a future compatible lint (it is already deny-by-default). The expected impact is low, as the majority of crates do not allow this lint (since declaring a constant that errors on evaluation, but not wanting compilation to stop, is quite odd).

Correct.

does this comment sound accurate?

Modulo the correction above, it does.

[RalfJung]

The one annoying effect of this PR is that let _x = &(1/(1-1)); now also shows the future-incompat warning, even though of course we will not make this a hard error.

This is resolved now that #80579 and #81333 landed. So there are no more "false future-compat positives".

[oli-obk]

r=me after a rebase

@bors p=1 very bitrotty

[RalfJung]

I think T-lang still needs to approve; the last status is

I would expect lang to just approve this next week; I do not think an FCP is needed as future incompatibility is not committing us to anything.

[joshtriplett]

We reviewed this in today's @rust-lang/lang meeting, and we agreed that we approve this change.

Please go ahead and merge as soon as the merge conflicts are addressed.

[RalfJung]

@bors r=oli-obk

[bors]

📌 Commit 8477d35 has been approved by oli-obk

[bors]

⌛ Testing commit 8477d35 with merge 120b2a7...