Out of cycle sync, as it is complicated and confusing to resolve merge
conflicts on the Rust side. This needs review for
eda3e649a41e0e73cb2e3ee6b98cbf8d7c12acae and
4d8766caaf11a14194406b8997243bb626000aae as well as the comment I'll
leave below.
changelog: none
This feature was stabilized, so the FormatArgs lints should check if the MSRV of
the stabilization is met, rather than checking if the feature is enabled.
It is not possible to write a declarative macro, that produces an
attribute w/o
an item attached to it. This means that the `check_item` will already
insert the
span in the map, if it came from an expansion. So additionally checking
if the
macro came from an expansion doesn't add anything here. So the
`check_attribute` function, and with that the problematic `attr.span()`
call can
be completely removed.
Fixes https://github.com/rust-lang/rust-clippy/issues/14303
r? @y21
cc @jdonszelmann
changelog: Fix ICE in [`macro_use_import`] lint
It is not possible to write a declarative macro, that produces an attribute w/o
an item attached to it. This means that the `check_item` will already insert the
span in the map, if it came from an expansion. So additionally checking if the
macro came from an expansion doesn't add anything here. So the
`check_attribute` function, and with that the problematic `attr.span()` call can
be completely removed.
Fixes#14303
The `looks_like_refdef` function was assuming the range was valid, this
just adds a check to ensure that is the case. It also works around a
subtraction underflow due to the same invalid range.
changelog: [`doc_nested_refdefs`]: Fix#14287 by avoiding invalid ranges
When the manually stripped entity receives a name as the first use
through a simple `let` statement, this name can be used in the generated
`if let Some(…)` expression instead of a placeholder.
Fix#14183
changelog: [`manual_strip`]: reuse existing identifier in suggestion
when possible
For some reason, the `todo!` and `unimplemented!` macros were not
included in the list of format-supporting macros list. Since they seem
to behave exactly the same as all others like `write!` and `assert!`,
adding them now.
I wonder if we should delete the `FORMAT_MACRO_DIAG_ITEMS`, and instead
tag all macros with the `#[clippy::format_args]`?
changelog: all format-handling lints will now validate `todo!` and
`unimplemented!` macros.
These method chains can be expressed concisely with `if`/`else`.
changelog: [`obfuscated_if_else`]: support `then().unwrap_or_else()` and
`then_some().unwrap_or_else()`
Give `global_asm` a fake body to store typeck results, represent `sym fn` as a hir expr to fix `sym fn` operands with lifetimes
There are a few intertwined problems with `sym fn` operands in both inline and global asm macros.
Specifically, unlike other anon consts, they may evaluate to a type with free regions in them without actually having an item-level type annotation to give them a "proper" type. This is in contrast to named constants, which always have an item-level type annotation, or unnamed constants which are constrained by their position (e.g. a const arg in a turbofish, or a const array length).
Today, we infer the type of the operand by looking at the HIR typeck results; however, those results are region-erased, so during borrowck we ICE since we don't expect to encounter erased regions. We can't just fill this type with something like `'static`, since we may want to use real (free) regions:
```rust
fn foo<'a>() {
asm!("/* ... */", sym bar::<&'a ()>);
}
```
The first idea may be to represent `sym fn` operands using *inline* consts instead of anon consts. This makes sense, since inline consts can reference regions from the parent body (like the `'a` in the example above). However, this introduces a problem with `global_asm!`, which doesn't *have* a parent body; inline consts *must* be associated with a parent body since they are not a body owner of their own. In #116087, I attempted to fix this by using two separate `sym` operands for global and inline asm. However, this led to a lot of confusion and also some unattractive code duplication.
In this PR, I adjust the lowering of `global_asm!` so that it's lowered in a "fake" HIR body. This body contains a single expression which is `ExprKind::InlineAsm`; we don't *use* this HIR body, but it's used in typeck and borrowck so that we can properly infer and validate the the lifetimes of `sym fn` operands.
I then adjust the lowering of `sym fn` to instead be represented with a HIR expression. This is both because it's no longer necessary to represent this operand as an anon const, since it's *just* a path expression, and also more importantly to sidestep yet another ICE (https://github.com/rust-lang/rust/issues/137179), which has to do with the existing code breaking an invariant of def-id creation and anon consts. Specifically, we are not allowed to synthesize a def-id for an anon const when that anon const contains expressions with def-ids whose parent is *not* that anon const. This is somewhat related to https://github.com/rust-lang/rust/pull/130443#issuecomment-2445678945, which is also a place in the compiler where synthesizing anon consts leads to def-id parenting issue.
As a side-effect, this consolidates the type checking for inline and global asm, so it allows us to simplify `InlineAsmCtxt` a bit. It also allows us to delete a bit of hacky code from anon const `type_of` which was there to detect `sym fn` operands specifically. This also could be generalized to support `const` asm operands with types with lifetimes in them. Since we specifically reject these consts today, I'm not going to change the representation of those consts (but they'd just be turned into inline consts).
r? oli-obk -- mostly b/c you're patient and also understand the breadth of the code that this touches, please reassign if you don't want to review this.
Fixes#111709Fixes#96304Fixes#137179
```rust
let mut tmp = vec![1, 2, 3];
for b in &mut tmp {
*b = !*b;
}
```
must not suggest the invalid `tmp.fill(!*b)`.
In addition, there is another commit which cleans up two function calls
with no effect.
Fix#14189
changelog: [`manual_slice_fill`]: ensure that the initialization
expression doesn't reference the iterator
More sophisticated span trimming for suggestions
Previously #136958 only cared about prefixes or suffixes. Now it detects more cases where a suggestion is "sandwiched" by unchanged code on the left or the right. Would be cool if we could detect several insertions, like `ACE` going to `ABCDE`, extracting `B` and `D`, but that seems unwieldy.
r? `@estebank`
- The name of an MSRV alias should describe its functionality, and it is
not appropriate for it to be the same as the name of the lint that uses
it.
- Additionally, while `manual_div_ceil` allows setting MSRV, this is not
correctly reflected in the configuration information.
changelog: none
Simplify `Postorder` customization.
`Postorder` has a `C: Customization<'tcx>` parameter, that gives it flexibility about how it computes successors. But in practice, there are only two `impls` of `Customization`, and one is for the unit type.
This commit simplifies things by removing the generic parameter and replacing it with an `Option`.
r? ````@saethlin````
For some reason, the `todo!` and `unimplemented!` macros were not included in the list of format-supporting macros list. Since they seem to behave exactly the same as all others like `write!` and `assert!`, adding them now.
