In general, needless_option_take should report whenever
take() is called on a temporary value, not just when the
temporary value is created by as_ref()
This should address #13099 for the derivable_impls test. As this
combines everything into a single multipart_suggestion, the feedback
message is a little less "targeted" than it was before, but now it
provides a complete`--fix`able suggestion - e.g.:
```
error: this binding can be a slice pattern to avoid indexing
--> tests/ui-toml/max_suggested_slice_pattern_length/index_refutable_slice.rs:5:17
|
LL | if let Some(slice) = slice {
| ^^^^^
|
note: the lint level is defined here
--> tests/ui-toml/max_suggested_slice_pattern_length/index_refutable_slice.rs:1:9
|
LL | #![deny(clippy::index_refutable_slice)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
help: replace the binding and indexed access with a slice pattern
|
LL ~ if let Some([_, _, _, _, _, _, _, slice_7, ..]) = slice {
LL |
LL | // This would usually not be linted but is included now due to the
LL | // index limit in the config file
LL ~ println!("{}", slice_7);
|
```
changelog: [index_refutable_slice]: Fixed multipart_suggestions to
provide correct rustfix-able lint
When we expand a `mod foo;` and parse `foo.rs`, we now track whether that file had an unrecovered parse error that reached the end of the file. If so, we keep that information around. When resolving a path like `foo::bar`, we do not emit any errors for "`bar` not found in `foo`", as we know that the parse error might have caused `bar` to not be parsed and accounted for.
When this happens in an existing project, every path referencing `foo` would be an irrelevant compile error. Instead, we now skip emitting anything until `foo.rs` is fixed. Tellingly enough, we didn't have any test for errors caused by `mod` expansion.
Fix#97734.
Make `Copy` unsafe to implement for ADTs with `unsafe` fields
As a rule, the application of `unsafe` to a declaration requires that use-sites of that declaration also entail `unsafe`. For example, a field declared `unsafe` may only be read in the lexical context of an `unsafe` block.
For nearly all safe traits, the safety obligations of fields are explicitly discharged when they are mentioned in method definitions. For example, idiomatically implementing `Clone` (a safe trait) for a type with unsafe fields will require `unsafe` to clone those fields.
Prior to this commit, `Copy` violated this rule. The trait is marked safe, and although it has no explicit methods, its implementation permits reads of `Self`.
This commit resolves this by making `Copy` conditionally safe to implement. It remains safe to implement for ADTs without unsafe fields, but unsafe to implement for ADTs with unsafe fields.
Tracking: #132922
r? ```@compiler-errors```
fix ICE on type error in promoted
Fixes https://github.com/rust-lang/rust/issues/133968
Ensure that when we turn a type error into a "this promoted failed to evaluate" error, we do record this as something that may happen even in "infallible" promoteds.
Initial implementation of `#[feature(default_field_values]`, proposed in https://github.com/rust-lang/rfcs/pull/3681.
Support default fields in enum struct variant
Allow default values in an enum struct variant definition:
```rust
pub enum Bar {
Foo {
bar: S = S,
baz: i32 = 42 + 3,
}
}
```
Allow using `..` without a base on an enum struct variant
```rust
Bar::Foo { .. }
```
`#[derive(Default)]` doesn't account for these as it is still gating `#[default]` only being allowed on unit variants.
Support `#[derive(Default)]` on enum struct variants with all defaulted fields
```rust
pub enum Bar {
#[default]
Foo {
bar: S = S,
baz: i32 = 42 + 3,
}
}
```
Check for missing fields in typeck instead of mir_build.
Expand test with `const` param case (needs `generic_const_exprs` enabled).
Properly instantiate MIR const
The following works:
```rust
struct S<A> {
a: Vec<A> = Vec::new(),
}
S::<i32> { .. }
```
Add lint for default fields that will always fail const-eval
We *allow* this to happen for API writers that might want to rely on users'
getting a compile error when using the default field, different to the error
that they would get when the field isn't default. We could change this to
*always* error instead of being a lint, if we wanted.
This will *not* catch errors for partially evaluated consts, like when the
expression relies on a const parameter.
Suggestions when encountering `Foo { .. }` without `#[feature(default_field_values)]`:
- Suggest adding a base expression if there are missing fields.
- Suggest enabling the feature if all the missing fields have optional values.
- Suggest removing `..` if there are no missing fields.
Clarify the relationship between indexing_slicing and
out_of_bound_indexing, clarify that this lint is about possible panics
based on runtime values, and fix array example to not trigger the
out_of_bound_indexing lint.
This addresses #13099 for the manual_async_fn test.
changelog: [manual_async_fn]: Updated manual_async_fn to use
multipart_suggestions where appropriate
There are two modules in `clippy_utils` that are currently in the form
of:
```
src/
| ast_utils/
| ty/
|
| ast_utils.rs
| ty.rs
```
This PR moves the top-level modules to become `mod.rs`, within their
respective folders.
```
src/
| ast_utils/
| | mod.rs
|
| ty/
| | mod.rs
```
This reduces clutter in the `src` folder, and makes it easier to find
related files in certain editors.[^0] This also appears to be the
standard used in other crates in this repository, though I looked very
briefly.
I do realize that this is a style / opinionated change, so I'll close it
if it receives much push-back. :)
[^0]: I use VSCode, which groups all folders together and all files
separately. This means that `ty.rs` is quite "far" away from the `ty/`
folder, which makes it move difficult to navigate between the two.
```
changelog: none
```
- \[x] `cargo test` passes locally
- \[x] Run `cargo dev fmt`
As a rule, the application of `unsafe` to a declaration requires that use-sites
of that declaration also require `unsafe`. For example, a field declared
`unsafe` may only be read in the lexical context of an `unsafe` block.
For nearly all safe traits, the safety obligations of fields are explicitly
discharged when they are mentioned in method definitions. For example,
idiomatically implementing `Clone` (a safe trait) for a type with unsafe fields
will require `unsafe` to clone those fields.
Prior to this commit, `Copy` violated this rule. The trait is marked safe, and
although it has no explicit methods, its implementation permits reads of `Self`.
This commit resolves this by making `Copy` conditionally safe to implement. It
remains safe to implement for ADTs without unsafe fields, but unsafe to
implement for ADTs with unsafe fields.
Tracking: #132922
This addresses #13099 for the manual_split_once test, using the
str_splitn lint.
changelog: [str_splitn]: Updated str_splitn to use multipart_suggestions
where appropriate
It was inconsistently done (sometimes even within a single function) and
most of the rest of the compiler uses fatal errors instead, which need
to be caught using catch_with_exit_code anyway. Using fatal errors
instead of ErrorGuaranteed everywhere in the driver simplifies things a
bit.
I ran [Typos](https://github.com/crate-ci/typos) on the project and
fixed all of the easy spelling mistakes! I made sure to avoid UI tests,
since those changes are more challenging to review due to the changes in
`.stderr` files.
```
changelog: Fixed several typos.
```
- \[x] `cargo test` passes locally
- \[x] Run `cargo dev fmt`
This PR updates the `borrow_as_ptr` lint to no longer suggest `addr_of!`
and `addr_of_mut!` and instead use the preferred `&raw const` and `&raw
mut` syntax.
Not sure about two things:
1. Do I need to set or update a MSRV for the lint anywhere?
2. There is a `borrow_as_ptr_no_std` test as well as a `borrow_as_ptr`
test. They used to be more relevant as the lint needed to select `std`
or `core`, but that is gone now, so maybe the `borrow_as_ptr_no_std`
should be deleted?
changelog: update `borrow_as_ptr` to suggest `&raw` syntax
Add lint against function pointer comparisons
This is kind of a follow-up to https://github.com/rust-lang/rust/pull/117758 where we added a lint against wide pointer comparisons for being ambiguous and unreliable; well function pointer comparisons are also unreliable. We should IMO follow a similar logic and warn people about it.
-----
## `unpredictable_function_pointer_comparisons`
*warn-by-default*
The `unpredictable_function_pointer_comparisons` lint checks comparison of function pointer as the operands.
### Example
```rust
fn foo() {}
let a = foo as fn();
let _ = a == foo;
```
### Explanation
Function pointers comparisons do not produce meaningful result since they are never guaranteed to be unique and could vary between different code generation units. Furthermore different function could have the same address after being merged together.
----
This PR also uplift the very similar `clippy::fn_address_comparisons` lint, which only linted on if one of the operand was an `ty::FnDef` while this PR lints proposes to lint on all `ty::FnPtr` and `ty::FnDef`.
```@rustbot``` labels +I-lang-nominated
~~Edit: Blocked on https://github.com/rust-lang/libs-team/issues/323 being accepted and it's follow-up pr~~
Change `AttrArgs::Eq` to a struct variant
Cleanups for simplifying https://github.com/rust-lang/rust/pull/131808
Basically changes `AttrArgs::Eq` to a struct variant and then avoids several matches on `AttrArgsEq` in favor of methods on it. This will make future refactorings simpler, as they can either keep methods or switch to field accesses without having to restructure code
https://github.com/rust-lang/rust/issues/133150
This is more likely to be intended as an intra-doc link than it is to be
intended as a refdef. If a refdef is intended, it does not need to be
nested within a list item.
```markdown
- [`LONG_INTRA_DOC_LINK`]: this
looks like an intra-doc link,
but is actually a refdef.
The first line will seem to
disappear when rendered as HTML.
```
> - [`LONG_INTRA_DOC_LINK`]: this
> looks like an intra-doc link,
> but is actually a refdef.
> The first line will seem to
> disappear when rendered as HTML.
changelog: [`doc_nested_refdefs`]: add suspicious lint for link def at
start of list items and block quotes
Fixes#13748
Diagnostic for that issue with this change:
```
warning: spawned process is not `wait()`ed on in all code paths
--> x.rs:167:19
|
167 | let mut cmd = cmd.unwrap();
| ^^^^^^^^^^^^
|
note: no `wait()` call exists on the code path to this early return
--> x.rs:178:47
|
178 | std::io::ErrorKind::BrokenPipe => return Some(0),
| ^^^^^^^^^^^^^^
note: `wait()` call exists, but it is unreachable due to the early return
--> x.rs:185:10
|
185 | Some(cmd.wait().unwrap().code().unwrap()) // <-- wait()!
| ^^^
= help: consider calling `.wait()` in all code paths
= note: not doing so might leave behind zombie processes
= note: see https://doc.rust-lang.org/stable/std/process/struct.Child.html#warning
```
Instead of saying "wait() is **never** called", it now says it's not
called by all code paths and points out the early return in particular.
changelog: none
