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
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 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
remove `Ty::is_copy_modulo_regions`
Using these functions is likely incorrect if an `InferCtxt` is available, I moved this function to `TyCtxt` (and added it to `LateContext`) and added a note to the documentation that one should prefer `Infer::type_is_copy_modulo_regions` instead.
I didn't yet move `is_sized` and `is_freeze`, though I think we should move these as well.
r? `@compiler-errors` cc #132279
Eliminate magic numbers from expression precedence
Context: see https://github.com/rust-lang/rust/pull/133140.
This PR continues on backporting Syn's expression precedence design into rustc. Rustc's design used mysterious integer quantities represented variously as `i8` or `usize` (e.g. `PREC_CLOSURE = -40i8`), a special significance around `0` that is never named, and an extra `PREC_FORCE_PAREN` precedence level that does not correspond to any expression. Syn's design uses a C-like enum with variants that clearly correspond to specific sets of expression kinds.
This PR is a refactoring that has no intended behavior change on its own, but it unblocks other precedence work that rustc's precedence design was poorly suited to accommodate.
- Asymmetrical precedence, so that a pretty-printer can tell `(return 1) + 1` needs parens but `1 + return 1` does not.
- Squashing the `Closure` and `Jump` cases into a single precedence level.
- Numerous remaining false positives and false negatives in rustc pretty-printer's parenthesization of macro metavariables, for example in `$e < rhs` where $e is `lhs as Thing<T>`.
FYI `@fmease` — you don't need to review if rustbot picks someone else, but you mentioned being interested in the followup PRs.
The new cases are the application of `Into::into` or `From::from`
through the following functions with no effect:
- `Option::map()`
- `Result::map()` and `Result::map_err()`
- `ControlFlow::map_break()` and `ControlFlow::map_err()`
- `Iterator::map()`
changelog: [`useless_conversion`]: detect useless calls to `Into::into`
and `From::from` application through `map*` methods
Remove `hir::ArrayLen`
This refactoring removes `hir::ArrayLen`, replacing it with `hir::ConstArg`. To represent inferred array lengths (previously `hir::ArrayLen::Infer`), a new variant `ConstArgKind::Infer` is added.
r? `@BoxyUwU`
Closes#13574
Make sure that `needless_match` doesn't simplify:
```
if let Some(_) = a() {
// ..
} else let Some(_) = b() {
// ..
}
```
to:
```
a()
```
changelog: [`needless_match`]: Fix false-positive on if lets
