Assignments to a captured variable within a diverging closure should not
be considered unused if the divergence is caught.
This patch considers such assignments/captures to be used by diverging
closures irrespective of whether the divergence is caught, but better a
false negative unused lint than a false positive one (the latter having
caused a stable-to-stable regression).
(cherry picked from commit 58292e2a53)
[beta] backports, plus stable versions in stdarch
- Replace `stdarch` version placeholders with 1.94
- Parse ident with allowing recovery when trying to diagnose rust-lang/rust#151249
- Revert enabling `outline-atomics` on various platforms rust-lang/rust#151896
- Revert doc attribute parsing errors to future warnings rust-lang/rust#151952
- Remove the 4 failing tests from rustdoc-gui rust-lang/rust#152194
- Remove rustdoc GUI flaky test rust-lang/rust#152116
- Align `ArrayWindows` trait impls with `Windows` rust-lang/rust#151613
- Fix suppression of `unused_assignment` in binding of `unused_variable` rust-lang/rust#151556
- layout: handle rigid aliases without params rust-lang/rust#151814
- Fix missing unused_variables lint when using a match guard rust-lang/rust#151990
- Partially revert "resolve: Update `NameBindingData::vis` in place" rust-lang/rust#152498
- [BETA]: parse array lengths without stripping const blocks rust-lang/rust#152237
r? cuviper
Within a binding pattern match guard, only real reads of a bound local
impact its liveness analysis - not the fake read that is injected.
(cherry picked from commit 5aba6b1635)
aliases may be rigid even if they don't reference params. If the alias isn't well-formed, trying to normalize it as part of the input should have already failed
(cherry picked from commit 39a532445a)
Unused assignments to an unused variable should trigger only the
`unused_variables` lint and not also the `unused_assignments` lint.
This was previously implemented by checking whether the span of the
assignee was within the span of the binding pattern, however that failed
to capture situations was imported from elsewhere (eg from the input
tokenstream of a proc-macro that generates the binding pattern).
By comparing the span of the assignee to those of the variable
introductions instead, a reported stable-to-stable regression is
resolved.
This fix also impacted some other preexisting tests, which had
(undesirably) been triggering both the `unused_variables` and
`unused_assignments` lints on the same initializing assignment; those
tests have therefore now been updated to expect only the former lint.
(cherry picked from commit 22b3f59882)
The derived `T: Copy` constraint is not appropriate for an iterator by
reference, but we generally do not want `Copy` on iterators anyway.
(cherry picked from commit 2bae85ec52)
Add `const Default` impls for `HashSet` and `HashMap` with custom `Hasher`
Follow up to rust-lang/rust#134628. Tracking issue rust-lang/rust#143894.
r? @fmease
cc @fee1-dead @oli-obk
This doesn't allow for `const H: HashSet<()> = Default::default();`, but would allow for it to work with a custom hasher, which would enable the `Fx*` family to work.
Fix ICE: When Trying to check visibility of a #[type_const], check RHS instead.
This PR fixes https://github.com/rust-lang/rust/issues/150956 for min_const_generic_args https://github.com/rust-lang/rust/issues/132980.
The first part of this PR checks in `reachable.rs` if we have a type const use `visit_const_item_rhs(init);` instead of calling `const_eval_poly_to_alloc()`
The second part is I noticed that if `const_eval_poly_to_alloc()` returns a `ErrorHandled::TooGeneric` then switches to `visit_const_item_rhs()`. So further up `const_eval_poly_to_alloc()` call order it eventual gets to `eval_in_interpreter()`. So I added a debug_assert in `eval_in_interpreter()` if we happen to try and run CTFE on a `type_const`.
The other bit is just a test case, and some duplicated code I noticed.
While the PR does get rid of the ICE for a type_const with `pub` visibility. If I try using the const though it will ICE with the following:
```
error: internal compiler error: /home/keith/GitHub/rust_kc/compiler/rustc_const_eval/src/check_consts/qualifs.rs:355:13: expected ConstKind::Param or ConstKind::Value here, found UnevaluatedConst { def: DefId(20:4 ~ colorkit[c783]::TYPE_CONST), args: [] }
thread 'rustc' (819687) panicked at /home/keith/GitHub/rust_kc/compiler/rustc_const_eval/src/check_consts/qualifs.rs:355:13:
```
I suspect it is a similar issue to inherent associated consts. Since if I apply the same fix I had here:
https://github.com/rust-lang/rust/pull/150799#discussion_r2676504639
I then can use the const internally and in external crates without any issues.
Although, did not include that fix since if it is a similar issue it would need to be addressed elsewhere.
r? @BoxyUwU
@rustbot label +F-associated_const_equality +F-min_generic_const_args
bors