Improve diagnostic for wrong borrow on binary operations
This PR improves the diagnostic for wrong borrow on binary operations by suggesting to reborrow on appropriate expressions.
```diff
+ = note: an implementation for `&Foo * &Foo` exist
+ help: consider reborrowing both sides
+ |
+ LL | let _ = &*ref_mut_foo * &*ref_mut_foo;
+ | ++ ++
```
Fixes https://github.com/rust-lang/rust/issues/109352
coverage: Replace `ExpressionOperandId` with enum `Operand`
*This is one step in my larger coverage refactoring ambitions described at <https://github.com/rust-lang/compiler-team/issues/645>.*
LLVM coverage has a concept of “mapping expressions” that allow a span's execution count to be computed as a simple arithmetic expression over other counters/expressions, instead of requiring a dedicated physical counter for every control-flow branch.
These expressions have an operator (`+` or `-`) and two operands. Operands are currently represented as `ExpressionOperandId`, which wraps a `u32` with the following semantics:
- 0 represents a special counter that always has a value of zero
- Values ascending from 1 represent counter IDs
- Values descending from `u32::MAX` represent the IDs of other expressions
---
This change replaces that whole `ExpressionOperandId` scheme with a simple enum that explicitly distinguishes between the three cases.
This lets us remove a lot of fiddly code for dealing with the different operand kinds:
- Previously it was only possible to distinguish between counter-ID operands and expression-ID operands by comparing the operand ID with the total number of counters in a function. This is unnecessary now that the enum distinguishes them explicitly.
- There's no need for expression IDs to descend from `u32::MAX` and then get translated into zero-based indices in certain places. Now that they ascend from zero, they can be used as indices directly.
- There's no need to reserve ID number 0 for the special zero operand, since it can just have its own variant in the enum, so counter IDs can count up from 0.
(Making counter IDs ascend from 0 also lets us fix an off-by-one error in the query for counting the total number of counters, which would cause LLVM to emit an extra unused counter for every instrumented function.)
---
This PR may be easiest to review as individual patches, since that breaks it up into clearly distinct parts:
- Replace a `u32` wrapper with an explicit enum, without changing the semantics of the underlying IDs being stored.
- Change the numbering scheme used by `Operand::Expression` to make expression IDs ascend from 0 (instead of descending from `u32::MAX`).
- Change the numbering scheme used by `Operand::Counter` to make counter IDs ascend from 0 (instead of ascending from 1).
Change default panic handler message format.
This changes the default panic hook's message format from:
```
thread '{thread}' panicked at '{message}', {location}
```
to
```
thread '{thread}' panicked at {location}:
{message}
```
This puts the message on its own line without surrounding quotes, making it easiser to read. For example:
Before:
```
thread 'main' panicked at 'env variable `IMPORTANT_PATH` should be set by `wrapper_script.sh`', src/main.rs:4:6
```
After:
```
thread 'main' panicked at src/main.rs:4:6:
env variable `IMPORTANT_PATH` should be set by `wrapper_script.sh`
```
---
See this PR by `@nyurik,` which does that for only multi-line messages (specifically because of `assert_eq`): https://github.com/rust-lang/rust/pull/111071
This is the change that does that for *all* panic messages.
Operand types are now tracked explicitly, so there is no need to reserve ID 0
for the special always-zero counter.
As part of the renumbering, this change fixes an off-by-one error in the way
counters were counted by the `coverageinfo` query. As a result, functions
should now have exactly the number of counters they actually need, instead of
always having an extra counter that is never used.
Operand types are now tracked explicitly, so there is no need for expression
IDs to avoid counter IDs by descending from `u32::MAX`. Instead they can just
count up from 0, and can be used directly as indices when necessary.
Because the three kinds of operand are now distinguished explicitly, we no
longer need fiddly code to disambiguate counter IDs and expression IDs based on
the total number of counters/expressions in a function.
This does increase the size of operands from 4 bytes to 8 bytes, but that
shouldn't be a big deal since they are mostly stored inside boxed structures,
and the current coverage code is not particularly size-optimized anyway.
Detect trait upcasting through struct tail unsizing in new solver select
Oops, we were able to hide trait upcasting behind a parent unsize goal that evaluated to `Certainty::Yes`. Let's do rematching for `Certainty::Yes` unsize goals with `BuiltinImplSource::Misc` sources (corresponding to all of the other unsize rules) to make sure we end up selecting any nested goals which may be satisfied via `BuiltinImplSource::TraitUpcasting` or `::TupleUnsizing`.
r? ``@lcnr``
Update lexer emoji diagnostics to Unicode 15.0
This replaces the `unic-emoji-char` dep tree (which hasn't been updated for a while) with `unicode-properties` crate which contains Unicode 15.0 data.
Improves diagnostics for added emoji characters in recent years. (See tests).
cc #101840
cc ``@Manishearth``
Fix ice tests when librustc-driver is linked dynamically
Running `dump-ice-to-disk`and `short-ice` tests on Linux targeting `x86_64-fortanix-unknown-sgx` platform results in:
```
jenkins@31cf43196355:~/workspace/rust-sgx-ci/Raoul/rust$ cat /home/jenkins/workspace/rust-sgx-ci/Raoul/rust/build/x86_64-unknown-linux-gnu/test/run-make/dump-ice-to-disk/dump-ice-to-disk/*
/home/jenkins/workspace/rust-sgx-ci/Raoul/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc: error while loading shared libraries: librustc_driver-fa98927b935b2881.so: cannot open shared object file: No such file or directory
/home/jenkins/workspace/rust-sgx-ci/Raoul/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc: error while loading shared libraries: librustc_driver-fa98927b935b2881.so: cannot open shared object file: No such file or directory
/home/jenkins/workspace/rust-sgx-ci/Raoul/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc: error while loading shared libraries: librustc_driver-fa98927b935b2881.so: cannot open shared object file: No such file or directory
/home/jenkins/workspace/rust-sgx-ci/Raoul/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc: error while loading shared libraries: librustc_driver-fa98927b935b2881.so: cannot open shared object file: No such file or directory
```
Setting the LD_LIBRARY_PATH explicitly to `$(HOST_RPATH_DIR)` in these tests Makefiles resolves the issue. The `thumb-none-qemu` and `thumb-none-cortex-m` run-make tests do something similar.
cc: ```@jethrogb``` ```@vn971``` ```@mkaynov```
Map RPITIT's opaque type bounds back from projections to opaques
An RPITIT in a program's AST is eventually translated into both a projection GAT and an opaque. The opaque is used for default trait methods, like:
```
trait Foo {
fn bar() -> impl Sized { 0i32 }
}
```
The item bounds for both the projection and opaque are identical, and both have a *projection* self ty. This is mostly okay, since we can normalize this projection within the default trait method body to the opaque, but it does two things:
1. it leads to bugs in places where we don't normalize item bounds, like `deduce_future_output_from_obligations`
2. it leads to extra match arms that are both suspicious looking and also easy to miss
This PR maps the opaque type bounds of the RPITIT's *opaque* back to the opaque's self type to avoid this quirk. Then we can fix the UI test for #108304 (1.) and also remove a bunch of match arms (2.).
Fixes#108304
r? `@spastorino`
Check lazy type aliases for well-formedness
Previously we didn't check if `T: Mul` holds given lazy `type Alias<T> = <T as Mul>::Output;`.
Now we do. It only makes sense.
`@rustbot` label F-lazy_type_alias
r? `@oli-obk`
Only golden arches
A number of tests in the test suite have applied the somewhat comedic practice of ignoring *every* single target architecture that rustc has ever supported. This is silly, when they are clearly tests built around certain assumptions, primarily of the x86-64 architecture, or in one case when they are only relevant for a handful of 32-bit targets. This has even resulted, in one case, in the same architecture being ignored twice!
Document these better, and use a "revision + only-arch" idiom in the test headers to denote the "golden arches" that actually pass these tests.
Don't install default projection bound for return-position `impl Trait` in trait methods with no body
This ensures that we never try to project to an opaque type in a trait method that has no body to infer its hidden type, which means we never later call `type_of` on that opaque. This is because opaque types try to reveal their hidden type when proving auto traits.
I thought about this a lot, and I think this is a fix that's less likely to introduce other strange downstream ICEs than #113461.
Fixes#113434
r? `@spastorino`
Fix invalid suggestion for mismatched types in closure arguments
This PR fixes the invalid suggestion for mismatched types in closure arguments.
The invalid suggestion came from a wrongly created span in the parser for closure arguments that don't have a type specified. Specifically, the span in this case was the last token span, but in the case of tuples, the span represented the last parenthesis instead of the whole tuple, which is fixed by taking the more accurate span of the pattern.
There is one unfortunate downside of this fix, it worsens even more the diagnostic for mismatched types in closure args without an explicit type. This happens because there is no correct span for implied inferred type. I tried also fixing this but it's a rabbit hole.
Fixes https://github.com/rust-lang/rust/issues/114180
`const`-stablilize `NonNull::as_ref`
A bunch of pointer to reference methods have been made unstably const some time ago in #91823 under the feature gate `const_ptr_as_ref`.
Out of these, `NonNull::as_ref` can be implemented as a `const fn` in stable rust today, so i hereby propose to const stabilize this function only.
Tracking issue: #91822
``@rustbot`` label +T-libs-api -T-libs
The invalid suggestion came from a wrongly created span in `rustc_parse'
for closure arguments that didn't have a type specified. Specifically,
the span in this case was the last token span, but in the case of
tuples, the span represented the last parenthesis instead of the whole
tuple, which is fixed by taking the more accurate span of the pattern.
Combining revisions with only-arch allows specifying
that a test only applies to a handful of targets.
This allows removing a large amount of repetition
in the test suite for tests that do not benefit.
The revisions are suboptimal for this for some tests,
so they aren't preferred in those cases.
Slightly more complicated: also give them appropriate names
that somewhat describe the cases they are trying to cover,
using information from PR chatter in rust-lang/rust#47158
Gracefully handle ternary operator
Fixes#112578
~~May not be the best way to do this as it doesn't check for a single `:`, so it could perhaps appear even when the actual issue is just a missing semicolon. May not be the biggest deal, though?~~
Nevermind, got it working properly now ^^
Update the minimum external LLVM to 15
With this change, we'll have stable support for LLVM 15 through 17 (pending release).
For reference, the previous increase to LLVM 14 was #107573.
Refactor + improve diagnostics for `&mut T`/`T` mismatch inside Option/Result
Follow up to #114052. This also makes the diagnostics structured + translatable.
r? `@WaffleLapkin`
Rename and allow `cast_ref_to_mut` lint
This PR is a small subset of https://github.com/rust-lang/rust/pull/112431, that is the renaming of the lint (`cast_ref_to_mut` -> `invalid_reference_casting`).
BUT also temporarily change the default level of the lint from deny-by-default to allow-by-default until https://github.com/rust-lang/rust/pull/112431 is merged.
r? `@Nilstrieb`
I could not find a test for this particular use case. The closest I got
was `tests/ui/imports/issue-37887.rs`, but that is a regression test
for a different use case.
fix(resolve): update the ambiguity glob binding as warning recursively
Fixes#47525Fixes#56593, but `issue-56593-2.rs` is not fixed to ensure backward compatibility.
Fixes#98467Fixes#105235Fixes#112713
This PR had added a field called `warn_ambiguous` in `NameBinding` which is only for back compatibly reason and used for lint.
More details: https://github.com/rust-lang/rust/pull/112743
r? `@petrochenkov`
Rollup of 7 pull requests
Successful merges:
- #113773 (Don't attempt to compute layout of type referencing error)
- #114107 (Prevent people from assigning me as a PR reviewer)
- #114124 (tests/ui/proc-macro/*: Migrate FIXMEs to check-pass)
- #114171 (Fix switch-stdout test for none unix/windows platforms)
- #114172 (Fix issue_15149 test for the SGX target)
- #114173 (btree/map.rs: remove "Basic usage" text)
- #114174 (doc: replace wrong punctuation mark)
r? `@ghost`
`@rustbot` modify labels: rollup
tests/ui/proc-macro/*: Migrate FIXMEs to check-pass
proc-macros are processed early in the compiler pipeline. There is no need to involve codegen. So change to check-pass.
I have also looked through each changed test and to me it is sufficiently clear that codegen is not needed for the purpose of the test.
I skipped changing `tests/ui/proc-macro/no-missing-docs.rs` in this commit because it was not clear to me that it can be changed to check-pass.
Part of #62277
Rollup of 7 pull requests
Successful merges:
- #114099 (privacy: no nominal visibility for assoc fns )
- #114128 (When flushing delayed span bugs, write to the ICE dump file even if it doesn't exist)
- #114138 (Adjust spans correctly for fn -> method suggestion)
- #114146 (Skip reporting item name when checking RPITIT GAT's associated type bounds hold)
- #114147 (Insert RPITITs that were shadowed by missing ADTs that resolve to [type error])
- #114155 (Replace a lazy `RefCell<Option<T>>` with `OnceCell<T>`)
- #114164 (Add regression test for `--cap-lints allow` and trait bounds warning)
r? `@ghost`
`@rustbot` modify labels: rollup
Add regression test for `--cap-lints allow` and trait bounds warning
Closes#43134
I have verified that the test fails if stderr begins to contain output by making sure the test fails when I add
eprintln!("some output on stderr");
to the compiler (I added it to `fn build_session()`).
Skip reporting item name when checking RPITIT GAT's associated type bounds hold
Doesn't really make sense to label an item that has a name that users can't really mention. Fixes#114145. Also fixes#113794.
r? `@spastorino`
privacy: no nominal visibility for assoc fns
Fixes#113860.
When `staged_api` is enabled, effective visibilities are computed earlier and this can trigger an ICE in some cases.
In particular, if a impl of a trait method has a visibility then an error will be reported for that, but when privacy invariants are being checked, the effective visibility will still be greater than the nominal visbility and that will trigger a `span_bug!`.
However, this invariant - that effective visibilites are limited to nominal visibility - doesn't make sense for associated functions.
Diagnostic namespace
This PR implements the basic infrastructure for accepting the `#[diagnostic]` attribute tool namespace as specified in https://github.com/rust-lang/rfcs/pull/3368. Note: This RFC is not merged yet, but it seems like it will be accepted soon. I open this PR early on to get feedback on the actual implementation as soon as possible. This hopefully enables getting at least the diagnostic namespace to stable rust "soon", so that crates do not need to bump their MSRV if we stabilize actual attributes in this namespace.
This PR only adds infrastructure accept attributes from this namespace, it does not add any specific attribute. Therefore the compiler will emit a lint warning for each attribute that's actually used. This namespace is added behind a feature flag, so it will be only available on a nightly compiler for now.
cc `@estebank` as they've supported me in planing, specifying and implementing this feature.
When `staged_api` is enabled, effective visibilities are computed earlier
and this can trigger an ICE in some cases.
In particular, if a impl of a trait method has a visibility then an error
will be reported for that, but when privacy invariants are being checked,
the effective visibility will still be greater than the nominal visbility
and that will trigger a `span_bug!`.
However, this invariant - that effective visibilites are limited to
nominal visibility - doesn't make sense for associated functions.
Signed-off-by: David Wood <david@davidtw.co>
I have verified that the test fails if stderr begins to contain output
by making sure the test fails when I add
eprintln!("some output on stderr");
to the compiler (I added it to `fn build_session()`).
Move two tests from `tests/ui/std` to `library/std/tests`
Hi, there,
This pull request comes from this issue (#99417), sorry I made some mistakes creating the pull request, it's my first one.
Regression test `println!()` panic message on `ErrorKind::BrokenPipe`
No existing test (that I could find) failed if the `panic!()` of the `println!()` family of functions was removed, or if its message was changed:
104f4300cf/library/std/src/io/stdio.rs (L1007-L1009)
So add such a test.
This is in preparation of adding a hint about the existence of [`unix_sigpipe`](https://github.com/rust-lang/rust/issues/97889) if that is the reason for the panic.
Even if we don't end up adding a hint, this is still a sensible test to have, I think.
`@rustbot` label +A-testsuite +A-io +T-libs +O-unix
tests/ui/hello_world/main.rs: Remove FIXME (#62277)
The purpose of the test is to make sure that compiling hello world produces no compiler output. To properly test that, we need to run the entire compiler pipeline. We don't want the test to pass if codegen accidentally starts writing to stdout. So keep it as build-pass.
Part of #62277
[rustdoc] If re-export is private, get the next item until a public one is found or expose the private item directly
Fixes#81141.
If we have:
```rust
use Private as Something;
pub fn foo() -> Something {}
```
Then `Something` will be replaced by `Private`.
r? `@notriddle`
Turns out opaque types can have hidden types registered during mir validation
See the newly added test's documentation for an explanation.
fixes#114121
Restore region uniquification in the new solver 🎉
All of the bugs that were "due" to uniquification have been settled via other means (e.g. bidirectional alias-relate, param-env incompleteness, etc).
Firstly, revert the functional changes in #110180. 😸
Secondly, we need to ignore regions when considering if a goal has changed (the "has_changed" boolean returned from `evaluate_goal`) -- otherwise, because we're doing region uniquification, we may perpetually consider a goal to be changed. See the UI test I committed for an explanation.
rustdoc: fix cross-crate `impl Sized` & `impl ?Sized`
Previously, cross-crate impl-Trait (APIT, RPIT, etc.) that only consists of a single `Sized` bound (modulo outlives-bounds) and ones that are `?Sized` were incorrectly rendered. To give you a taste (before vs. after):
```diff
- fn sized(x: impl ) -> impl
+ fn sized(x: impl Sized) -> impl Sized
- fn sized_outlives<'a>(x: impl 'a) -> impl 'a
+ fn sized_outlives<'a>(x: impl Sized + 'a) -> impl Sized + 'a
- fn maybe_sized(x: &impl ) -> &impl
+ fn maybe_sized(x: &impl ?Sized) -> &impl ?Sized
- fn debug_maybe_sized(x: &impl Debug) -> &impl ?Sized + Debug
+ fn debug_maybe_sized(x: &(impl Debug + ?Sized)) -> &(impl Debug + ?Sized)
```
Moreover, we now surround impl-Trait that has multiple bounds with parentheses if they're the pointee of a reference or raw pointer type. This affects both local and cross-crate docs. The current output isn't correct (rustc would emit the error *ambiguous `+` in a type* if we fed the rendered code back to it).
---
Best reviewed commit by commit :)
`@rustbot` label A-cross-crate-reexports
proc-macros are processed early in the compiler pipeline. There is no
need to involve codegen. So change to check-pass.
I have also looked through each changed test and to me it is
sufficiently clear that codegen is not needed for the purpose of the
test.
I skipped changing tests/ui/proc-macro/no-missing-docs.rs in this commit
because it was not clear to me that it can be changed to check-pass.
The purpose of the test is to make sure that compiling hello world
produces no compiler output. To properly test that, we need to run the
entire compiler pipeline. We don't want the test to pass if codegen
accidentally starts writing to stdout. So keep it as build-pass.
Replace in-tree `rustc_apfloat` with the new version of the crate
Replace the in-tree version of `rustc_apfloat` with the new version of the crate which has been correctly licensed. The new crate incorporates upstream changes from LLVM since the original port was done including many correctness fixes and has been extensively fuzz tested to validate correctness.
Fixes#100233Fixes#102403Fixes#113407Fixes#113409Fixes#55993Fixes#93224Closes#93225Closes#109573
Fix missing attribute merge on glob foreign re-exports
Fixes https://github.com/rust-lang/rust/issues/113982.
The attributes were not merged with the import's in case of glob re-export of foreign items.
r? `@notriddle`
lint/ctypes: fix `()` return type checks
Fixes#113436.
`()` is normally FFI-unsafe, but is FFI-safe when used as a return type. It is also desirable that a transparent newtype for `()` is FFI-safe when used as a return type.
In order to support this, when a type was deemed FFI-unsafe, because of a `()` type, and was used in return type - then the type was considered FFI-safe. However, this was the wrong approach - it didn't check that the `()` was part of a transparent newtype! The consequence of this is that the presence of a `()` type in a more complex return type would make it the entire type be considered safe (as long as the `()` type was the first that the lint found) - which is obviously incorrect.
Instead, this logic is removed, and after [consultation with t-lang](https://github.com/rust-lang/rust/issues/113436#issuecomment-1640756721), I've fixed the bugs and inconsistencies and made `()` FFI-safe within types.
I also refactor a function, but that's not too exciting.
new unstable option: -Zwrite-long-types-to-disk
This option guards the logic of writing long type names in files and instead using short forms in error messages in rustc_middle/ty/error behind a flag. The main motivation for this change is to disable this behaviour when running ui tests.
This logic can be triggered by running tests in a directory that has a long enough path, e.g. /my/very-long-path/where/rust-codebase/exists/
This means ui tests can fail depending on how long the path to their file is.
Some ui tests actually rely on this behaviour for their assertions, so for those we enable the flag manually.
Double check that hidden types match the expected hidden type
Fixes https://github.com/rust-lang/rust/issues/113278 specifically, but I left a TODO for where we should also add some hardening.
It feels a bit like papering over the issue, but at least this way we don't get unsoundness, but just surprising errors. Errors will be improved and given spans before this PR lands.
r? `@compiler-errors` `@lcnr`
Don't say that a type is uncallable if its fn signature has errors in it
This is fallout from #106309, where we don't consider param-env candidates that reference errors because they unify with everything. This means, however, that we don't consider an APIT like `impl Fn(MissingType)` isn't considered to implement `Fn`, for example.
We can double-check that with a weaker heuristic [`extract_callable_info`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir_typeck/fn_ctxt/struct.FnCtxt.html#method.extract_callable_info), and suppress the knock-down error using that.
Fixes#113566
Rollup of 7 pull requests
Successful merges:
- #114008 (coverage: Obtain the `__llvm_covfun` section name outside a per-function loop)
- #114014 (builtin_macros: expect raw strings too)
- #114043 (docs(LazyLock): add example pass local LazyLock variable to struct)
- #114051 (Add regression test for invalid "unused const" in method)
- #114052 (Suggest `{Option,Result}::as_ref()` instead of `cloned()` in some cases)
- #114058 (Add help for crate arg when crate name is invalid)
- #114060 (abi: unsized field in union - assert to delay bug )
r? `@ghost`
`@rustbot` modify labels: rollup
abi: unsized field in union - assert to delay bug
Fixes#113279.
> Unions cannot have unsized fields, and as such, layout computation for
unions asserts that each union field is sized (as this would normally
have halted compilation earlier).
>
> However, if a generator ends up with an unsized local - a circumstance
in which an error will always have been emitted earlier, for example, if
attempting to dereference a `&str` - then the generator transform will
produce a union with an unsized field.
>
> Since https://github.com/rust-lang/rust/pull/110107, later passes will be run, such as constant propagation,
and can attempt layout computation on the generator, which will result
in layout computation of `str` in the context of it being a field of a
union - and so the aforementioned assertion would cause an ICE.
>
> It didn't seem appropriate to try and detect this case in the MIR body
and skip this specific pass; tainting the MIR body or delaying a bug
from the generator transform (or elsewhere) wouldn't prevent this either
(as neither would prevent the later pass from running); and tainting when
the deref of `&str` is reported, if that's possible, would unnecessarily
prevent potential other errors from being reported later in compilation,
and is very tailored to this specific case of getting a unsized type in
a generator.
>
> Given that this circumstance can only happen when an error should have
already been reported, the correct fix appears to be just changing the
assert to a delayed bug. This will still assert if there is some
circumstance where this occurs and no error has been reported, but it
won't crash the compiler in this instance.
While debugging this, I noticed a translation ICE in a delayed bug, so I fixed that too:
> During borrowck, the `MultiSpan` from a buffered diagnostic is cloned and
used to emit a delayed bug indicating a diagnostic was buffered - when
the buffered diagnostic is translated, then the cloned `MultiSpan` may
contain labels which can only render with the diagnostic's arguments, but
the delayed bug being emitted won't have those arguments. Adds a function
which clones `MultiSpan` without also cloning the contained labels, and
use this function when creating the buffered diagnostic delayed bug.
Suggest `{Option,Result}::as_ref()` instead of `cloned()` in some cases
Fixes#114050
When we have an expr available that produces the type expectation, we can suggest appending `.as_ref()` to the span, instead of cloning the expr producing the mismatch
Add regression test for invalid "unused const" in method
The warning can be reproduced with 1.63 but not with 1.64.
$ rustc +1.63 tests/ui/lint/unused/const-local-var.rs
warning: constant `F` is never used
--> tests/ui/lint/unused/const-local-var.rs:14:9
|
14 | const F: i32 = 2;
| ^^^^^^^^^^^^^^^^^
|
= note: `#[warn(dead_code)]` on by default
$ rustc +1.64 tests/ui/lint/unused/const-local-var.rs
Add a regression test to prevent the problem from re-appearing.
Closes#69016
