Liveness analysis for generators assumes that execution always continues
normally after a yield point, not accounting for the fact that generator
could be dropped before completion.
If generators captures any variables by reference, those variables could
be used within a generator, or when the generator completes, but also
after each yield point in the case the generator is dropped.
Account for the case when generator is dropped after yielding, but
before running to the completion. This effectively considers all
variables captured by reference to be used after a yield point.
Remove `Session.used_attrs` and move logic to `CheckAttrVisitor`
Instead of updating global state to mark attributes as used,
we now explicitly emit a warning when an attribute is used in
an unsupported position. As a side effect, we are to emit more
detailed warning messages (instead of just a generic "unused" message).
`Session.check_name` is removed, since its only purpose was to mark
the attribute as used. All of the callers are modified to use
`Attribute.has_name`
Additionally, `AttributeType::AssumedUsed` is removed - an 'assumed
used' attribute is implemented by simply not performing any checks
in `CheckAttrVisitor` for a particular attribute.
We no longer emit unused attribute warnings for the `#[rustc_dummy]`
attribute - it's an internal attribute used for tests, so it doesn't
mark sense to treat it as 'unused'.
With this commit, a large source of global untracked state is removed.
Warn about unreachable code following an expression with an uninhabited type
This pull request fixes#85071. The issue is that liveness analysis currently is "smarter" than reachability analysis when it comes to detecting uninhabited types: Unreachable code is detected during type checking, where full type information is not yet available. Therefore, the check for type inhabitedness is quite crude:
fc81ad22c4/compiler/rustc_typeck/src/check/expr.rs (L202-L205)
i.e. it only checks for `!`, but not other, non-trivially uninhabited types, such as empty enums, structs containing an uninhabited type, etc. By contrast, liveness analysis, which runs after type checking, can benefit from the more sophisticated `tcx.is_ty_uninhabited_from()`:
fc81ad22c4/compiler/rustc_passes/src/liveness.rs (L981)fc81ad22c4/compiler/rustc_passes/src/liveness.rs (L996)
This can lead to confusing warnings when a variable is reported as unused, but the use of the variable is not reported as unreachable. For instance:
```rust
enum Foo {}
fn f() -> Foo {todo!()}
fn main() {
let x = f();
let _ = x;
}
```
currently leads to
```
warning: unused variable: `x`
--> t1.rs:5:9
|
5 | let x = f();
| ^ help: if this is intentional, prefix it with an underscore: `_x`
|
= note: `#[warn(unused_variables)]` on by default
warning: 1 warning emitted
```
which is confusing, because `x` _appears_ to be used in line 6. With my changes, I get:
```
warning: unreachable expression
--> t1.rs:6:13
|
5 | let x = f();
| --- any code following this expression is unreachable
6 | let _ = x;
| ^ unreachable expression
|
= note: `#[warn(unreachable_code)]` on by default
note: this expression has type `Foo`, which is uninhabited
--> t1.rs:5:13
|
5 | let x = f();
| ^^^
warning: unused variable: `x`
--> t1.rs:5:9
|
5 | let x = f();
| ^ help: if this is intentional, prefix it with an underscore: `_x`
|
= note: `#[warn(unused_variables)]` on by default
warning: 2 warnings emitted
```
My implementation is slightly inelegant because unreachable code warnings can now be issued in two different places (during type checking and during liveness analysis), but I think it is the solution with the least amount of unnecessary code duplication, given that the new warning integrates nicely with liveness analysis, where unreachable code is already implicitly detected for the purpose of finding unused variables.
Get piece unchecked in `write`
We already use specialized `zip`, but it seems like we can do a little better by not checking `pieces` length at all.
`Arguments` constructors are now unsafe. So the `format_args!` expansion now includes an `unsafe` block.
<details>
<summary>Local Bench Diff</summary>
```text
name before ns/iter after ns/iter diff ns/iter diff % speedup
fmt::write_str_macro1 22,967 19,718 -3,249 -14.15% x 1.16
fmt::write_str_macro2 35,527 32,654 -2,873 -8.09% x 1.09
fmt::write_str_macro_debug 571,953 575,973 4,020 0.70% x 0.99
fmt::write_str_ref 9,579 9,459 -120 -1.25% x 1.01
fmt::write_str_value 9,573 9,572 -1 -0.01% x 1.00
fmt::write_u128_max 176 173 -3 -1.70% x 1.02
fmt::write_u128_min 138 134 -4 -2.90% x 1.03
fmt::write_u64_max 139 136 -3 -2.16% x 1.02
fmt::write_u64_min 129 135 6 4.65% x 0.96
fmt::write_vec_macro1 24,401 22,273 -2,128 -8.72% x 1.10
fmt::write_vec_macro2 37,096 35,602 -1,494 -4.03% x 1.04
fmt::write_vec_macro_debug 588,291 589,575 1,284 0.22% x 1.00
fmt::write_vec_ref 9,568 9,732 164 1.71% x 0.98
fmt::write_vec_value 9,516 9,625 109 1.15% x 0.99
```
</details>
Rollup of 6 pull requests
Successful merges:
- #87976 (Account for tabs when highlighting multiline code suggestions)
- #88174 (Clarify some wording in Rust 2021 lint docs)
- #88188 (Greatly improve limitation handling on parallel rustdoc GUI test run)
- #88230 (Fix typos “a”→“an”)
- #88232 (Add notes to macro-not-found diagnostics to point out how things with the same name were not a match.)
- #88259 (Do not mark `-Z thir-unsafeck` as unsound anymore)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Otherwise, we can get into a situation where you have
a subtype obligation `#1 <: #2` pending, #1 is constrained
by `check_casts`, but #2` is unaffected.
Co-authored-by: Niko Matsakis <niko@alum.mit.edu>
Add notes to macro-not-found diagnostics to point out how things with the same name were not a match.
This adds notes like:
```
error: cannot find derive macro `Serialize` in this scope
--> $DIR/issue-88206.rs:22:10
|
LL | #[derive(Serialize)]
| ^^^^^^^^^
|
note: `Serialize` is imported here, but it is not a derive macro
--> $DIR/issue-88206.rs:17:11
|
LL | use hey::{Serialize, Deserialize};
| ^^^^^^^^^
```
Fixes https://github.com/rust-lang/rust/issues/88206
Includes https://github.com/rust-lang/rust/pull/88229
r? `@estebank`
2229: Handle MutBorrow/UniqueImmBorrow better
We only want to use UniqueImmBorrow when the capture place is truncated and we
drop Deref of a MutRef.
r? `@nikomatsakis`
Fixes: https://github.com/rust-lang/project-rfc-2229/issues/56
Previously, converting `&mut [T; N]` to `&[Cell<T>; N]` looks like this:
let array = &mut [1, 2, 3];
let cells: &[Cell<i32>; 3] = Cell::from_mut(&mut array[..])
.as_slice_of_cells()
.try_into()
.unwrap();
With this new helper method, it looks like this:
let array = &mut [1, 2, 3];
let cells: &[Cell<i32>; 3] = Cell::from_mut(array).as_array_of_cells();
Rollup of 7 pull requests
Successful merges:
- #86747 (Improve wording of the `drop_bounds` lint)
- #87166 (Show discriminant before overflow in diagnostic for duplicate values.)
- #88077 (Generate an iOS LLVM target with a specific version)
- #88164 (PassWrapper: adapt for LLVM 14 changes)
- #88211 (cleanup: `Span::new` -> `Span::with_lo`)
- #88229 (Suggest importing the right kind of macro.)
- #88238 (Stop tracking namespace in used_imports.)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Improve wording of the `drop_bounds` lint
This PR addresses #86653. The issue is sort of a false positive of the `drop_bounds` lint, but I would argue that the best solution for #86653 is simply a rewording of the warning message and lint description, because even if the lint is _technically_ wrong, it still forces the programmer to think about what they are doing, and they can always use `#[allow(drop_bounds)]` if they think that they really need the `Drop` bound.
There are two issues with the current warning message and lint description:
- First, it says that `Drop` bounds are "useless", which is technically incorrect because they actually do have the effect of allowing you e.g. to call methods that also have a `Drop` bound on their generic arguments for some reason. I have changed the wording to emphasize not that the bound is "useless", but that it is most likely not what was intended.
- Second, it claims that `std::mem::needs_drop` detects whether a type has a destructor. But I think this is also technically wrong: The `Drop` bound says whether the type has a destructor or not, whereas `std::mem::needs_drop` also takes nested types with destructors into account, even if the top-level type does not itself have one (although I'm not 100% sure about the exact terminology here, i.e. whether the "drop glue" of the top-level type counts as a destructor or not).
cc `@jonhoo,` does this solve the issue for you?
r? `@GuillaumeGomez`
canonicalize consts before calling try_unify_abstract_consts query
Fixes#88022Fixes#86953Fixes#77708Fixes#82034Fixes#85031
these ICEs were all caused by calling the `try_unify_abstract_consts` query with inference vars in substs
r? `@lcnr`
