fix `Expr::can_have_side_effects` for `[x; N]` style array literal and binary expressions
AFAIK `[0; 3]` is basically a syntax sugar for `[0, 0, 0]` so it should return whether the repeat's element can have side effects, like what it does on arrays.
And it seems that the rule for unary operators and indexings can be applied to binary operators as well.
Merge `associated_const_equality` feature gate into MGCA
Tracking Issues: rust-lang/rust#132980rust-lang/rust#92827
Merge `associated_const_equality`(ACE) feature gate into `min_generic_const_args`(MGCA).
- Replaces `features().associated_const_equality()` checks with `features().min_generic_const_args()`
- Updates the parser to gate associated const equality under `min_generic_const_args`
- Moves `associated_const_equality` to the removed features list
- Removes the `associated_const_equality` method from the `Features` trait
- Updates all affected tests and tools (rust-analyzer, clippy)
Closesrust-lang/rust#150617
r? `@BoxyUwU`
This removes `associated_const_equality` as a separate feature gate and makes it part of `min_generic_const_args` (mgca).
Key changes:
- Remove `associated_const_equality` from unstable features, add to removed
- Update all test files to use `min_generic_const_args` instead
- Preserve the original "associated const equality is incomplete" error message by specially handling `sym::associated_const_equality` spans in `feature_gate.rs`
- Rename FIXME(associated_const_equality) to FIXME(mgca)
```
error[E0277]: the size for values of type `(dyn Debug + 'static)` cannot be known at compilation time
--> $DIR/dyn-trait-type-alias-return-type.rs:4:11
|
LL | fn f() -> T { loop {} }
| ^ doesn't have a size known at compile-time
|
= help: the trait `Sized` is not implemented for `(dyn Debug + 'static)`
note: this type alias is unsized
--> $DIR/dyn-trait-type-alias-return-type.rs:1:1
|
LL | type T = dyn core::fmt::Debug;
| ^^^^^^
= note: the return type of a function must have a statically known size
```
Add a warn-by-default `unused_visibility` lint for visibility qualifiers
on `const _` declarations - e.g. `pub const _: () = ();`.
These have no effect.
Warn against calls which mutate an interior mutable `const`-item
## `const_item_interior_mutations`
~~`interior_mutable_const_item_mutations`~~
~~`suspicious_mutation_of_interior_mutable_consts`~~
*warn-by-default*
The `const_item_interior_mutations` lint checks for calls which mutates an interior mutable const-item.
### Example
```rust
use std::sync::Once;
const INIT: Once = Once::new(); // using `INIT` will always create a temporary and
// never modify it-self on use, should be a `static`
// instead for shared use
fn init() {
INIT.call_once(|| {
println!("Once::call_once first call");
});
}
```
```text
warning: mutation of an interior mutable `const` item with call to `call_once`
--> a.rs:11:5
|
11 | INIT.call_once(|| {
| ^---
| |
| _____`INIT` is a interior mutable `const` item of type `std::sync::Once`
| |
12 | | println!("Once::call_once first call");
13 | | });
| |______^
|
= note: each usage of a `const` item creates a new temporary
= note: only the temporaries and never the original `const INIT` will be modified
= help: for more details on interior mutability see <https://doc.rust-lang.org/reference/interior-mutability.html>
= note: `#[warn(const_item_interior_mutations)]` on by default
help: for a shared instance of `INIT`, consider making it a `static` item instead
|
6 - const INIT: Once = Once::new(); // using `INIT` will always create a temporary and
6 + static INIT: Once = Once::new(); // using `INIT` will always create a temporary and
|
```
### Explanation
Calling a method which mutates an interior mutable type has no effect as const-item are essentially inlined wherever they are used, meaning that they are copied directly into the relevant context when used rendering modification through interior mutability ineffective across usage of that const-item.
The current implementation of this lint only warns on significant `std` and `core` interior mutable types, like `Once`, `AtomicI32`, ... this is done out of prudence and may be extended in the future.
----
This PR is an targeted alternative to rust-lang/rust#132146. It avoids false-positives by adding an internal-only attribute `#[rustc_should_not_be_called_on_const_items]` on methods and functions that mutates an interior mutale type through a shared reference (mutable refrences are already linted by the `const_item_mutation` lint).
It should also be noted that this is NOT an uplift of the more general [`clippy::borrow_interior_mutable_const`](https://rust-lang.github.io/rust-clippy/master/index.html#/borrow_interior_mutable_const) lint, which is a much more general lint regarding borrow of interior mutable types, but has false-positives that are completly avoided by this lint.
A simple [GitHub Search](https://github.com/search?q=lang%3Arust+%2F%28%3F-i%29const+%5Ba-zA-Z0-9_%5D*%3A+Once%2F&type=code) reveals many instance where the user probably wanted to use a `static`-item instead.
----
````@rustbot```` labels +I-lang-nominated +T-lang
cc ````@traviscross````
r? compiler
Fixes [IRLO - Forbidding creation of constant mutexes, etc](https://internals.rust-lang.org/t/forbidding-creation-of-constant-mutexes-etc/19005)
Fixes https://github.com/rust-lang/rust/issues/132028
Fixes https://github.com/rust-lang/rust/issues/40543
mgca: Add ConstArg representation for const items
tracking issue: rust-lang/rust#132980fixesrust-lang/rust#131046fixesrust-lang/rust#134641
As part of implementing `min_generic_const_args`, we need to distinguish const items that can be used in the type system, such as in associated const equality projections, from const items containing arbitrary const code, which must be kept out of the type system. Specifically, all "type consts" must be either concrete (no generics) or generic with a trivial expression like `N` or a path to another type const item.
To syntactically distinguish these cases, we require, for now at least, that users annotate all type consts with the `#[type_const]` attribute. Then, we validate that the const's right-hand side is indeed eligible to be a type const and represent it differently in the HIR.
We accomplish this representation using a new `ConstItemRhs` enum in the HIR, and a similar but simpler enum in the AST. When `#[type_const]` is **not** applied to a const (e.g. on stable), we represent const item right-hand sides (rhs's) as HIR bodies, like before. However, when the attribute is applied, we instead lower to a `hir::ConstArg`. This syntactically distinguishes between trivial const args (paths) and arbitrary expressions, which are represented using `AnonConst`s. Then in `generics_of`, we can take advantage of the existing machinery to bar the `AnonConst` rhs's from using parent generics.
When mgca is enabled, const rhs's that are paths may have false
negatives with the lints in non_copy_const.rs. But these should probably
be using the trait solver anyway, and it only happens under mgca.
fix: Only special case single line item attribute suggestions
`rustc` currently special cases suggestions to add [`#[derive(_)]\n` and other attributes](https://github.com/rust-lang/rust/blob/dc1feabef242259d61bd930713de3250577c1c71/compiler/rustc_errors/src/emitter.rs#L2288C36-L2288C72), to add more context to the suggestions.
> // The suggestion adds an entire line of code, ending on a newline, so we'll also
> // print the *following* line, to provide context of what we're advising people to
> // do. Otherwise you would only see contextless code that can be confused for
> // already existing code, despite the colors and UI elements.
> // We special case `#[derive(_)]\n` and other attribute suggestions, because those
> // are the ones where context is most useful.
This special case is a bit broad at the moment and applies to suggestions just to add an attribute, as well as suggestions that contain an attribute and other code, i.e.
```rust
#[derive(Clone)]
```
and
```rust
#[cfg(not(test))]
impl Default for NewWithCfg {
fn default() -> Self {
Self::new()
}
}
```
In the latter case, adding a line for context after the suggestion doesn't provide much benefit. Example:
This PR makes it so that this special case only applies to suggestions that just add an attribute and nothing else. This will also make `rustc`'s output match `annotate-snippets`.
Implement pin-project in pattern matching for `&pin mut|const T`
This PR implements part of rust-lang/rust#130494. It supports pin-project in pattern matching for `&pin mut|const T`.
~Pin-projection by field access (i.e. `&pin mut|const place.field`) is not fully supported yet since pinned-borrow is not ready (rust-lang/rust#135731).~
CC ``````@traviscross``````
Mark desugared range expression spans with DesugaringKind::RangeExpr
This is a prerequisite to removing `QPath::LangItem` (rust-lang/rust#115178) because otherwise there would be no way to detect a range expression in the HIR.
There are some non-obvious Clippy changes so a Clippy team review would be good.
test: Subtract code_offset from width for ui_testing
`annotate-snippets` does not have a "UI test" mode like `rustc`, [where the code offset is not subtracted from the column width](https://github.com/rust-lang/rust/blob/f34ba774c78ea32b7c40598b8ad23e75cdac42a6/compiler/rustc_errors/src/emitter.rs#L1985-L1987). This makes it so `annotate-snippets` will shift the output for some very long tests 5 - 7 columns to the left. As part of my work to have `rustc` use `annotate-snippets`, and to reduce the test differences between the two, I figured it would be best if `rustc` started subtracting the code offset from the width as well.
The first commit exists to keep the test output changes of adding a new line to a test separate from adding the `--diagnostic-width` flag in the second commit. This makes it easier to verify that adding the flag does not affect the test's output.
[Zulip discussion](https://rust-lang.zulipchat.com/#narrow/channel/147480-t-compiler.2Fdiagnostics/topic/annotate-snippets.20hurdles)
rust-bors[bot]