Commit Graph

2373 Commits

Author SHA1 Message Date
Matthias Krüger
e0039171ff
Rollup merge of #129678 - compiler-errors:type-ir-inherent, r=fmease
Deny imports of `rustc_type_ir::inherent` outside of type ir + new trait solver

We shouldn't encourage using `rustc_type_ir::inherent` outside of the new solver[^1], though this can happen by accident due to rust-analyzer, for example. See https://github.com/rust-lang/rust/pull/127537#discussion_r1733813842 for an example in practice.

r? fmease

[^1]: Unless we go the fully radical approach of always using these inherent methods everywhere in favor of inherent methods, which would be a major overhaul of the compiler, IMO. I don't really want to consider that possibility right now, tho.
2024-09-02 04:19:28 +02:00
Michael Goulet
91854453f2 Deny imports of rustc_type_ir::inherent outside of type ir + new trait solver 2024-09-01 12:16:18 -04:00
bors
a48861a627 Auto merge of #127313 - cjgillot:single-expect, r=jieyouxu
Rewrite lint_expectations in a single pass.

This PR aims at reducing the perf regression from https://github.com/rust-lang/rust/pull/120924#issuecomment-2202486203 with drive-by simplifications.

Basically, instead of using the lint level builder, which is slow, this PR splits `lint_expectations` logic in 2:
- listing the `LintExpectations` is done in `shallow_lint_levels_on`, on a per-owner basis;
- building the unstable->stable expectation id map is done by iterating on attributes.

r? ghost for perf
2024-09-01 15:50:48 +00:00
Matthias Krüger
1063c0dd37
Rollup merge of #129207 - GrigorenkoPV:elided-is-named, r=cjgillot
Lint that warns when an elided lifetime ends up being a named lifetime

As suggested in https://github.com/rust-lang/rust/issues/48686#issuecomment-1817334575

Fixes #48686
2024-09-01 03:58:03 +02:00
Camille GILLOT
ff1fc68c11 Simplify lint source computation. 2024-08-31 14:02:27 +00:00
Camille GILLOT
5f1f45b095 Remove attr_id from stable lint ids. 2024-08-31 14:01:07 +00:00
Camille GILLOT
111b0a97b4 Rewrite lint_expectations in a single pass. 2024-08-31 14:00:54 +00:00
Camille GILLOT
4928b22fa8 Use AttrId key for unstable<->stable expectation map. 2024-08-31 13:58:01 +00:00
Pavel Grigorenko
5d04472461 Implement elided_named_lifetimes lint 2024-08-31 15:35:41 +03:00
Matthias Krüger
5f10a99c7a
Rollup merge of #129725 - compiler-errors:predicates-of, r=fmease
Stop using `ty::GenericPredicates` for non-predicates_of queries

`GenericPredicates` is a struct of several parts: A list of of an item's own predicates, and a parent def id (and some effects related stuff, but ignore that since it's kinda irrelevant). When instantiating these generic predicates, it calls `predicates_of` on the parent and instantiates its predicates, and appends the item's own instantiated predicates too:

acb4e8b625/compiler/rustc_middle/src/ty/generics.rs (L407-L413)

Notice how this should result in a recursive set of calls to `predicates_of`... However, `GenericPredicates` is *also* misused by a bunch of *other* queries as a convenient way of passing around a list of predicates. For these queries, we don't ever set the parent def id of the `GenericPredicates`, but if we did, then this would be very easy to mistakenly call `predicates_of` instead of some other intended parent query.

Given that footgun, and the fact that we don't ever even *use* the parent def id in the `GenericPredicates` returned from queries like `explicit_super_predicates_of`, It really has no benefit over just returning `&'tcx [(Clause<'tcx>, Span)]`.

This PR additionally opts to wrap the results of `EarlyBinder`, as we've tended to use that in the return type of these kinds of queries to properly convey that the user has params to deal with, and it also gives a convenient way of iterating over a slice of things after instantiating.
2024-08-31 10:08:57 +02:00
Matthias Krüger
2a321e14a5
Rollup merge of #129527 - compiler-errors:lint-nit, r=Nadrieril
Don't use `TyKind` in a lint

Allows us to remove an inherent method from `TyKind` from the type ir crate.
2024-08-31 10:08:53 +02:00
Michael Goulet
92004523db Stop using ty::GenericPredicates for non-predicates_of queries 2024-08-29 00:17:40 -04:00
Nicholas Nethercote
f10284162f Add warn(unreachable_pub) to rustc_lint. 2024-08-27 15:24:11 +10:00
Matthias Krüger
114e60ff79
Rollup merge of #129600 - traviscross:TC/tie-impl_trait_overcaptures-to-rust-2024, r=compiler-errors
Tie `impl_trait_overcaptures` lint to Rust 2024

The `impl_trait_overcaptures` lint is part of the migration to Rust 2024 and the Lifetime Capture Rules 2024.  Now that we've stabilized precise capturing (RFC 3617), let's tie this lint to the `rust_2024_compatibility` lint group.

Tracking:

- https://github.com/rust-lang/rust/issues/117587

r? `@compiler-errors`
2024-08-26 17:25:34 +02:00
Travis Cross
6982785f18 Tie impl_trait_overcaptures lint to Rust 2024
The `impl_trait_overcaptures` lint is part of the migration to Rust
2024 and the Lifetime Capture Rules 2024.  Now that we've stabilized
precise capturing (RFC 3617), let's tie this lint to the
`rust_2024_compatibility` lint group.
2024-08-26 06:46:56 +00:00
bors
717aec0f8e Auto merge of #129521 - matthiaskrgr:rollup-uigv77m, r=matthiaskrgr
Rollup of 9 pull requests

Successful merges:

 - #128596 (stabilize const_fn_floating_point_arithmetic)
 - #129199 (make writes_through_immutable_pointer a hard error)
 - #129246 (Retroactively feature gate `ConstArgKind::Path`)
 - #129290 (Pin `cc` to 1.0.105)
 - #129323 (Implement `ptr::fn_addr_eq`)
 - #129500 (remove invalid `TyCompat` relation for effects)
 - #129501 (panicking: improve hint for Miri's RUST_BACKTRACE behavior)
 - #129505 (interpret: ImmTy: tighten sanity checks in offset logic)
 - #129510 (Fix `elided_named_lifetimes` in code)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-08-25 08:12:16 +00:00
Trevor Gross
198a68df1c
Rollup merge of #128735 - jieyouxu:pr-120176-revive, r=cjgillot
Add a special case for `CStr`/`CString` in the `improper_ctypes` lint

Revives #120176. Just needed to bless a test and fix an argument, but seemed reasonable to me otherwise.

Instead of saying to "consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute to this struct", we now tell users to "Use `*const ffi::c_char` instead, and pass the value from `CStr::as_ptr()`" when the type involved is a `CStr` or a `CString`.

The suggestion is not made for `&mut CString` or `*mut CString`.

r? ``````@cjgillot`````` (since you were the reviewer of the original PR #120176, but feel free to reroll)
2024-08-24 21:03:31 -05:00
Michael Goulet
42a901acd9 Don't use TyKind in lint 2024-08-24 17:16:39 -04:00
Matthias Krüger
05b8bcc662
Rollup merge of #129199 - RalfJung:writes_through_immutable_pointer, r=compiler-errors
make writes_through_immutable_pointer a hard error

This turns the lint added in https://github.com/rust-lang/rust/pull/118324 into a hard error. This has been reported in cargo's future-compat reports since Rust 1.76 (released in February). Given that const_mut_refs is still unstable, it should be impossible to even hit this error on stable: we did accidentally stabilize some functions that can cause this error, but that got reverted in https://github.com/rust-lang/rust/pull/117905. Still, let's do a crater run just to be sure.

Given that this should only affect unstable code, I don't think it needs an FCP, but let's Cc ``@rust-lang/lang`` anyway -- any objection to making this unambiguous UB into a hard error during const-eval? This can be viewed as part of https://github.com/rust-lang/rust/pull/129195 which is already nominated for discussion.
2024-08-24 22:14:12 +02:00
bors
a60a9e567a Auto merge of #129464 - GuillaumeGomez:rollup-ckfqd7h, r=GuillaumeGomez
Rollup of 9 pull requests

Successful merges:

 - #128511 (Document WebAssembly target feature expectations)
 - #129243 (do not build `cargo-miri` by default on stable channel)
 - #129263 (Add a missing compatibility note in the 1.80.0 release notes)
 - #129276 (Stabilize feature `char_indices_offset`)
 - #129350 (adapt integer comparison tests for LLVM 20 IR changes)
 - #129408 (Fix handling of macro arguments within the `dropping_copy_types` lint)
 - #129426 (rustdoc-search: use tighter json for names and parents)
 - #129437 (Fix typo in a help diagnostic)
 - #129457 (kobzol vacation)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-08-23 10:56:34 +00:00
Guillaume Gomez
81aca633bb
Rollup merge of #129408 - Urgau:macro-arg-drop_copy, r=compiler-errors
Fix handling of macro arguments within the `dropping_copy_types` lint

This PR fixes the handling of spans with different context (aka macro arguments) than the primary expression within the different `{drop,forget}ing_copy_types` and `{drop,forget}ing_references` lints.

<details>
<summary>Before</summary>

```
warning: calls to `std::mem::drop` with a value that implements `Copy` does nothing
 --> drop_writeln.rs:5:5
  |
5 |     drop(writeln!(&mut msg, "test"));
  |     ^^^^^--------------------------^
  |          |
  |          argument has type `Result<(), std::fmt::Error>`
  |
  = note: `#[warn(dropping_copy_types)]` on by default
help: use `let _ = ...` to ignore the expression or result
 --> /home/[..]/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/macros/mod.rs:688:9
  |
68|         let _ =
  |         ~~~~~~~
```

</details>

<details>
<summary>With this PR</summary>

```
warning: calls to `std::mem::drop` with a value that implements `Copy` does nothing
 --> drop_writeln.rs:5:5
  |
5 |     drop(writeln!(&mut msg, "test"));
  |     ^^^^^--------------------------^
  |          |
  |          argument has type `Result<(), std::fmt::Error>`
  |
  = note: `#[warn(dropping_copy_types)]` on by default
help: use `let _ = ...` to ignore the expression or result
  |
5 -     drop(writeln!(&mut msg, "test"));
5 +     let _ = writeln!(&mut msg, "test");
  |
```

</details>

``````@rustbot`````` label +L-dropping_copy_types
2024-08-23 12:32:16 +02:00
Matthias Krüger
487b3d92cf
Rollup merge of #129386 - cjgillot:local-resolved-arg, r=compiler-errors
Use a LocalDefId in ResolvedArg.
2024-08-23 06:26:53 +02:00
Urgau
6a878a9630 Fix handling of macro arguments within the `dropping_copy_types lint 2024-08-22 13:32:01 +02:00
bors
739b1fdb15 Auto merge of #129365 - matthiaskrgr:rollup-ebwx6ya, r=matthiaskrgr
Rollup of 9 pull requests

Successful merges:

 - #127279 (use old ctx if has same expand environment during decode span)
 - #127945 (Implement `debug_more_non_exhaustive`)
 - #128941 ( Improve diagnostic-related lints: `untranslatable_diagnostic` & `diagnostic_outside_of_impl`)
 - #129070 (Point at explicit `'static` obligations on a trait)
 - #129187 (bootstrap: fix clean's remove_dir_all implementation)
 - #129231 (improve submodule updates)
 - #129264 (Update `library/Cargo.toml` in weekly job)
 - #129284 (rustdoc: animate the `:target` highlight)
 - #129302 (compiletest: use `std::fs::remove_dir_all` now that it is available)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-08-22 05:17:27 +00:00
Camille GILLOT
c51f2d24d1 Use a LocalDefId in ResolvedArg. 2024-08-22 01:17:01 +00:00
Matthias Krüger
47af700fe6
Rollup merge of #128941 - GrigorenkoPV:internal-diagnostic-lints, r=davidtwco
Improve diagnostic-related lints: `untranslatable_diagnostic` & `diagnostic_outside_of_impl`

Summary:
- Made `untranslatable_diagnostic` point to problematic arguments instead of the function call
  (I found this misleading while working on some `A-translation` PRs: my first impression was that
  the methods themselves were not translation-aware and needed to be changed,
  while in reality the problem was with the hardcoded strings passed as arguments).
- Made the shared pass of `untranslatable_diagnostic` & `diagnostic_outside_of_impl` more efficient.

`@rustbot` label D-imprecise-spans A-translation
2024-08-21 19:35:11 +02:00
Matthias Krüger
937a18daf9
Rollup merge of #129344 - compiler-errors:less-option-unit-diagnostics, r=jieyouxu
Use `bool` in favor of `Option<()>` for diagnostics

We originally only supported `Option<()>` for optional notes/labels, but we now support `bool`. Let's use that, since it usually leads to more readable code.

I'm not removing the support from the derive macro, though I guess we could error on it... 🤔
2024-08-21 18:15:05 +02:00
Michael Goulet
25ff9b6bcb Use bool in favor of Option<()> for diagnostics 2024-08-21 01:31:11 -04:00
Ding Xiang Fei
ef25fbd0b4
lint on tail expr drop order change in Edition 2024 2024-08-21 01:05:21 +08:00
bors
a971212545 Auto merge of #127672 - compiler-errors:precise-capturing, r=spastorino
Stabilize opaque type precise capturing (RFC 3617)

This PR partially stabilizes opaque type *precise capturing*, which was specified in [RFC 3617](https://github.com/rust-lang/rfcs/pull/3617), and whose syntax was amended by FCP in [#125836](https://github.com/rust-lang/rust/issues/125836).

This feature, as stabilized here, gives us a way to explicitly specify the generic lifetime parameters that an RPIT-like opaque type captures.  This solves the problem of overcapturing, for lifetime parameters in these opaque types, and will allow the Lifetime Capture Rules 2024 ([RFC 3498](https://github.com/rust-lang/rfcs/pull/3498)) to be fully stabilized for RPIT in Rust 2024.

### What are we stabilizing?

This PR stabilizes the use of a `use<'a, T>` bound in return-position impl Trait opaque types.  Such a bound fully specifies the set of generic parameters captured by the RPIT opaque type, entirely overriding the implicit default behavior.  E.g.:

```rust
fn does_not_capture<'a, 'b>() -> impl Sized + use<'a> {}
//                               ~~~~~~~~~~~~~~~~~~~~
//                This RPIT opaque type does not capture `'b`.
```

The way we would suggest thinking of `impl Trait` types *without* an explicit `use<..>` bound is that the `use<..>` bound has been *elided*, and that the bound is filled in automatically by the compiler according to the edition-specific capture rules.

All non-`'static` lifetime parameters, named (i.e. non-APIT) type parameters, and const parameters in scope are valid to name, including an elided lifetime if such a lifetime would also be valid in an outlives bound, e.g.:

```rust
fn elided(x: &u8) -> impl Sized + use<'_> { x }
```

Lifetimes must be listed before type and const parameters, but otherwise the ordering is not relevant to the `use<..>` bound.  Captured parameters may not be duplicated.  For now, only one `use<..>` bound may appear in a bounds list.  It may appear anywhere within the bounds list.

### How does this differ from the RFC?

This stabilization differs from the RFC in one respect: the RFC originally specified `use<'a, T>` as syntactically part of the RPIT type itself, e.g.:

```rust
fn capture<'a>() -> impl use<'a> Sized {}
```

However, settling on the final syntax was left as an open question.  T-lang later decided via FCP in [#125836](https://github.com/rust-lang/rust/issues/125836) to treat `use<..>` as a syntactic bound instead, e.g.:

```rust
fn capture<'a>() -> impl Sized + use<'a> {}
```

### What aren't we stabilizing?

The key goal of this PR is to stabilize the parts of *precise capturing* that are needed to enable the migration to Rust 2024.

There are some capabilities of *precise capturing* that the RFC specifies but that we're not stabilizing here, as these require further work on the type system.  We hope to lift these limitations later.

The limitations that are part of this PR were specified in the [RFC's stabilization strategy](https://rust-lang.github.io/rfcs/3617-precise-capturing.html#stabilization-strategy).

#### Not capturing type or const parameters

The RFC addresses the overcapturing of type and const parameters; that is, it allows for them to not be captured in opaque types.  We're not stabilizing that in this PR.  Since all in scope generic type and const parameters are implicitly captured in all editions, this is not needed for the migration to Rust 2024.

For now, when using `use<..>`, all in scope type and const parameters must be nameable (i.e., APIT cannot be used) and included as arguments.  For example, this is an error because `T` is in scope and not included as an argument:

```rust
fn test<T>() -> impl Sized + use<> {}
//~^ ERROR `impl Trait` must mention all type parameters in scope in `use<...>`
```

This is due to certain current limitations in the type system related to how generic parameters are represented as captured (i.e. bivariance) and how inference operates.

We hope to relax this in the future, and this stabilization is forward compatible with doing so.

#### Precise capturing for return-position impl Trait **in trait** (RPITIT)

The RFC specifies precise capturing for RPITIT.  We're not stabilizing that in this PR.  Since RPITIT already adheres to the Lifetime Capture Rules 2024, this isn't needed for the migration to Rust 2024.

The effect of this is that the anonymous associated types created by RPITITs must continue to capture all of the lifetime parameters in scope, e.g.:

```rust
trait Foo<'a> {
    fn test() -> impl Sized + use<Self>;
    //~^ ERROR `use<...>` precise capturing syntax is currently not allowed in return-position `impl Trait` in traits
}
```

To allow this involves a meaningful amount of type system work related to adding variance to GATs or reworking how generics are represented in RPITITs.  We plan to do this work separately from the stabilization.  See:

- https://github.com/rust-lang/rust/pull/124029

Supporting precise capturing for RPITIT will also require us to implement a new algorithm for detecting refining capture behavior.  This may involve looking through type parameters to detect cases where the impl Trait type in an implementation captures fewer lifetimes than the corresponding RPITIT in the trait definition, e.g.:

```rust
trait Foo {
    fn rpit() -> impl Sized + use<Self>;
}

impl<'a> Foo for &'a () {
    // This is "refining" due to not capturing `'a` which
    // is implied by the trait's `use<Self>`.
    fn rpit() -> impl Sized + use<>;

    // This is not "refining".
    fn rpit() -> impl Sized + use<'a>;
}
```

This stabilization is forward compatible with adding support for this later.

### The technical details

This bound is purely syntactical and does not lower to a [`Clause`](https://doc.rust-lang.org/1.79.0/nightly-rustc/rustc_middle/ty/type.ClauseKind.html) in the type system.  For the purposes of the type system (and for the types team's curiosity regarding this stabilization), we have no current need to represent this as a `ClauseKind`.

Since opaques already capture a variable set of lifetimes depending on edition and their syntactical position (e.g. RPIT vs RPITIT), a `use<..>` bound is just a way to explicitly rather than implicitly specify that set of lifetimes, and this only affects opaque type lowering from AST to HIR.

### FCP plan

While there's much discussion of the type system here, the feature in this PR is implemented internally as a transformation that happens before lowering to the type system layer.  We already support impl Trait types partially capturing the in scope lifetimes; we just currently only expose that implicitly.

So, in my (errs's) view as a types team member, there's nothing for types to weigh in on here with respect to the implementation being stabilized, and I'd suggest a lang-only proposed FCP (though we'll of course CC the team below).

### Authorship and acknowledgments

This stabilization report was coauthored by compiler-errors and TC.

TC would like to acknowledge the outstanding and speedy work that compiler-errors has done to make this feature happen.

compiler-errors thanks TC for authoring the RFC, for all of his involvement in this feature's development, and pushing the Rust 2024 edition forward.

### Open items

We're doing some things in parallel here.  In signaling the intention to stabilize, we want to uncover any latent issues so we can be sure they get addressed.  We want to give the maximum time for discussion here to happen by starting it while other remaining miscellaneous work proceeds.  That work includes:

- [x] Look into `syn` support.
  - https://github.com/dtolnay/syn/issues/1677
  - https://github.com/dtolnay/syn/pull/1707
- [x] Look into `rustfmt` support.
  - https://github.com/rust-lang/rust/pull/126754
- [x] Look into `rust-analyzer` support.
  - https://github.com/rust-lang/rust-analyzer/issues/17598
  - https://github.com/rust-lang/rust-analyzer/pull/17676
- [x] Look into `rustdoc` support.
  - https://github.com/rust-lang/rust/issues/127228
  - https://github.com/rust-lang/rust/pull/127632
  - https://github.com/rust-lang/rust/pull/127658
- [x] Suggest this feature to RfL (a known nightly user).
- [x] Add a chapter to the edition guide.
  - https://github.com/rust-lang/edition-guide/pull/316
- [x] Update the Reference.
  - https://github.com/rust-lang/reference/pull/1577

### (Selected) implementation history

* https://github.com/rust-lang/rfcs/pull/3498
* https://github.com/rust-lang/rfcs/pull/3617
* https://github.com/rust-lang/rust/pull/123468
* https://github.com/rust-lang/rust/issues/125836
* https://github.com/rust-lang/rust/pull/126049
* https://github.com/rust-lang/rust/pull/126753

Closes #123432.

cc `@rust-lang/lang` `@rust-lang/types`

`@rustbot` labels +T-lang +I-lang-nominated +A-impl-trait +F-precise_capturing

Tracking:

- https://github.com/rust-lang/rust/issues/123432

----

For the compiler reviewer, I'll leave some inline comments about diagnostics fallout :^)

r? compiler
2024-08-20 10:42:55 +00:00
Michael Goulet
eae5b5c6e7 Stabilize opaque type precise capturing 2024-08-17 12:33:29 -04:00
Ralf Jung
8b642a1883 make writes_through_immutable_pointer a hard error 2024-08-17 14:49:35 +02:00
Michael Goulet
833af65f38 Use FnSig instead of raw FnDecl for ForeignItemKind::Fn 2024-08-16 14:10:06 -04:00
Matthias Krüger
bb63d75ac1
Rollup merge of #129065 - nnethercote:PartialEq-TokenKind, r=spastorino
Use `impl PartialEq<TokenKind> for Token` more.

This lets us compare a `Token` with a `TokenKind`. It's used a lot, but can be used even more, avoiding the need for some `.kind` uses.

r? `@spastorino`
2024-08-15 19:32:35 +02:00
Nicholas Nethercote
7923b20dd9 Use impl PartialEq<TokenKind> for Token more.
This lets us compare a `Token` with a `TokenKind`. It's used a lot, but
can be used even more, avoiding the need for some `.kind` uses.
2024-08-14 16:37:09 +10:00
bors
9859bf27fd Auto merge of #129076 - matthiaskrgr:rollup-rg8mi2x, r=matthiaskrgr
Rollup of 6 pull requests

Successful merges:

 - #128410 (Migrate `remap-path-prefix-dwarf` `run-make` test to rmake)
 - #128759 (alloc: add ToString specialization for `&&str`)
 - #128873 (Add windows-targets crate to std's sysroot)
 - #129001 (chore(lib): Enhance documentation for core::fmt::Formatter's write_fm…)
 - #129061 (Use `is_lang_item` more)
 - #129062 (Remove a no-longer-true assert)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-08-14 04:17:13 +00:00
Matthias Krüger
cd6852b9ea
Rollup merge of #129061 - compiler-errors:lang-item, r=Urgau
Use `is_lang_item` more

Few places that I missed since introducing `TyCtxt::is_lang_item`.
2024-08-14 05:05:52 +02:00
bors
e9c965df7b Auto merge of #128812 - nnethercote:shrink-TyKind-FnPtr, r=compiler-errors
Shrink `TyKind::FnPtr`.

By splitting the `FnSig` within `TyKind::FnPtr` into `FnSigTys` and `FnHeader`, which can be packed more efficiently. This reduces the size of the hot `TyKind` type from 32 bytes to 24 bytes on 64-bit platforms. This reduces peak memory usage by a few percent on some benchmarks. It also reduces cache misses and page faults similarly, though this doesn't translate to clear cycles or wall-time improvements on CI.

r? `@compiler-errors`
2024-08-14 00:56:53 +00:00
Michael Goulet
bac19686a5 Use is_lang_item more 2024-08-13 16:44:53 -04:00
Guillaume Gomez
ea74eff55c
Rollup merge of #128886 - GrigorenkoPV:untranslatable-diagnostic, r=nnethercote
Get rid of some `#[allow(rustc::untranslatable_diagnostic)]`

`@rustbot` label +A-translation
cc https://github.com/rust-lang/rust/issues/100717
2024-08-12 17:09:17 +02:00
Matthias Krüger
32e0fe129d
Rollup merge of #128762 - fmease:use-more-slice-pats, r=compiler-errors
Use more slice patterns inside the compiler

Nothing super noteworthy. Just replacing the common 'fragile' pattern of "length check followed by indexing or unwrap" with slice patterns for legibility and 'robustness'.

r? ghost
2024-08-11 07:51:51 +02:00
Pavel Grigorenko
e94a4ee219 Refactor: diagnostic_outside_of_impl, untranslatable_diagnostic
1. Decouple them.
2. Make logic around `diagnostic_outside_of_impl`'s early exits simpler.
3. Make `untranslatable_diagnostic` run one loop instead of two
   and not allocate an intermediate vec.
4. Overall, reduce the amount of code executed
   when the lints do not end up firing.
2024-08-10 21:53:01 +03:00
Pavel Grigorenko
3cc2a6fdcb untranslatable_diagnostic lint: point at the untranslated thing
and not the function/method call
2024-08-10 20:36:33 +03:00
Pavel Grigorenko
2babab6e43 rustc_lint: remove some redundant #[allow(rustc::untranslatable_diagnostic)] 2024-08-10 14:32:56 +03:00
Michael Howell
4dc13c5471 diagnostics: do not warn when a lifetime bound infers itself 2024-08-09 16:16:16 -07:00
Nicholas Nethercote
c4717cc9d1 Shrink TyKind::FnPtr.
By splitting the `FnSig` within `TyKind::FnPtr` into `FnSigTys` and
`FnHeader`, which can be packed more efficiently. This reduces the size
of the hot `TyKind` type from 32 bytes to 24 bytes on 64-bit platforms.
This reduces peak memory usage by a few percent on some benchmarks. It
also reduces cache misses and page faults similarly, though this doesn't
translate to clear cycles or wall-time improvements on CI.
2024-08-09 14:33:25 +10:00
bors
8b3870784f Auto merge of #128796 - matthiaskrgr:rollup-r7l68ph, r=matthiaskrgr
Rollup of 8 pull requests

Successful merges:

 - #128221 (Add implied target features to target_feature attribute)
 - #128261 (impl `Default` for collection iterators that don't already have it)
 - #128353 (Change generate-copyright to generate HTML, with cargo dependencies included)
 - #128679 (codegen: better centralize function declaration attribute computation)
 - #128732 (make `import.vis` is immutable)
 - #128755 (Integrate crlf directly into related test file instead via of .gitattributes)
 - #128772 (rustc_codegen_ssa: Set architecture for object crate for 32-bit SPARC)
 - #128782 (unused_parens: do not lint against parens around &raw)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-08-07 20:00:29 +00:00
Ralf Jung
c1897960c0 unused_parens: do not lint against parens around &raw 2024-08-07 15:29:00 +02:00
Urgau
c0c57b3e29 Disallow setting built-in cfgs via set the command-line 2024-08-07 14:08:34 +02:00
Urgau
eedb32dd12 Make Span optional in BufferedEarlyLint 2024-08-07 14:08:34 +02:00
León Orell Valerian Liehr
c4c518d2d4
Use more slice patterns inside the compiler 2024-08-07 13:37:52 +02:00
Matthias Krüger
5f9ebb5d26
Rollup merge of #128517 - clubby789:overflowing-lit-span, r=petrochenkov
Fallback to string formatting if source is not available for lint

Fixes #128445
2024-08-06 20:23:39 +02:00
Matthias Krüger
d3d9aae960
Rollup merge of #128369 - GrigorenkoPV:let-underscore-translatable, r=davidtwco
rustc_lint: make `let-underscore-lock` translatable
2024-08-06 20:23:38 +02:00
Flying-Toast
b335ec9ec8 Add a special case for CStr/CString in the improper_ctypes lint
Instead of saying to "consider adding a `#[repr(C)]` or
`#[repr(transparent)]` attribute to this struct", we now tell users to
"Use `*const ffi::c_char` instead, and pass the value from
`CStr::as_ptr()`" when the type involved is a `CStr` or a `CString`.

Co-authored-by: Jieyou Xu <jieyouxu@outlook.com>
2024-08-06 13:56:59 +00:00
Matthias Krüger
d10f2b32f0
Rollup merge of #127907 - RalfJung:byte_slice_in_packed_struct_with_derive, r=nnethercote
built-in derive: remove BYTE_SLICE_IN_PACKED_STRUCT_WITH_DERIVE hack and lint

Fixes https://github.com/rust-lang/rust/issues/107457 by turning the lint into a hard error. The lint has been shown in future breakage reports since Rust 1.69 (released in April 2023).

Let's see (via crater) if enough time has passed since https://github.com/rust-lang/rust/pull/104429, and https://github.com/unicode-org/icu4x/pull/2834 has propagated far enough to let us make this a hard error.

Cc ``@nnethercote`` ``@Manishearth``
2024-08-05 05:40:19 +02:00
Matthias Krüger
2f549aac39
Rollup merge of #128368 - nnethercote:rustfmt-tweaks, r=cuviper
Formatting tweaks

Some small post-#125443 formatting tweaks.

r? ``@cuviper``
2024-08-03 11:17:44 +02:00
clubby789
3cd445a5b6 Fallback to string formatting if source is not available 2024-08-01 20:29:39 +00:00
Ralf Jung
5d5c97aad7 interpret: simplify pointer arithmetic logic 2024-08-01 14:25:19 +02:00
bors
e485266c67 Auto merge of #128461 - matthiaskrgr:rollup-3dpp11g, r=matthiaskrgr
Rollup of 7 pull requests

Successful merges:

 - #123813 (Add `REDUNDANT_IMPORTS` lint for new redundant import detection)
 - #126697 ([RFC] mbe: consider the `_` in 2024 an expression)
 - #127159 (match lowering: Hide `Candidate` from outside the lowering algorithm)
 - #128244 (Peel off explicit (or implicit) deref before suggesting clone on move error in borrowck, remove some hacks)
 - #128431 (Add myself as VxWorks target maintainer for reference)
 - #128438 (Add special-case for [T, 0] in dropck_outlives)
 - #128457 (Fix docs for OnceLock::get_mut_or_init)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-08-01 02:26:32 +00:00
Urgau
840ca3cbef Temporarily switch ambiguous_negative_literals lint to allow 2024-07-31 19:36:47 +02:00
Michael Goulet
f6f587e7ea Introduce REDUNDANT_IMPORTS lint 2024-07-31 00:07:42 -04:00
Pavel Grigorenko
c9346a1f05 rustc_lint: make let-underscore-lock translatable 2024-07-30 00:34:27 +03:00
Nicholas Nethercote
70fcf9e790 Insert some blank lines.
After things that are immediately followed by a `use` declaration and
look like they might apply to that `use` item but actually don't.
2024-07-30 07:25:15 +10:00
Nicholas Nethercote
84ac80f192 Reformat use declarations.
The previous commit updated `rustfmt.toml` appropriately. This commit is
the outcome of running `x fmt --all` with the new formatting options.
2024-07-29 08:26:52 +10:00
Ralf Jung
bda31d14f4 built-in derive: remove BYTE_SLICE_IN_PACKED_STRUCT_WITH_DERIVE hack and lint 2024-07-27 18:18:41 +02:00
bors
7c2012d0ec Auto merge of #121676 - Bryanskiy:polarity, r=petrochenkov
Support ?Trait bounds in supertraits and dyn Trait under a feature gate

This patch allows `maybe` polarity bounds under a feature gate. The only language change here is that corresponding hard errors are replaced by feature gates. Example:
```rust
#![feature(allow_maybe_polarity)]
...
trait Trait1 : ?Trait { ... } // ok
fn foo(_: Box<(dyn Trait2 + ?Trait)>) {} // ok
fn bar<T: ?Sized + ?Trait>(_: &T) {} // ok
```
Maybe bounds still don't do anything (except for `Sized` trait), however this patch will allow us to [experiment with default auto traits](https://github.com/rust-lang/rust/pull/120706#issuecomment-1934006762).

This is a part of the [MCP: Low level components for async drop](https://github.com/rust-lang/compiler-team/issues/727)
2024-07-26 20:14:16 +00:00
Trevor Gross
ceae37188b
Rollup merge of #126575 - fmease:update-lint-type_alias_bounds, r=compiler-errors
Make it crystal clear what lint `type_alias_bounds` actually signifies

This is part of my work on https://github.com/rust-lang/rust/labels/F-lazy_type_alias ([tracking issue](#112792)).

---

To recap, the lint `type_alias_bounds` detects bounds on generic parameters and where clauses on (eager) type aliases. These bounds should've never been allowed because they are currently neither enforced[^1] at usage sites of type aliases nor thoroughly checked for correctness at definition sites due to the way type aliases are represented in the compiler. Allowing them was an oversight.

Explicitly label this as a known limitation of the type checker/system and establish the experimental feature `lazy_type_alias` as its eventual proper solution.

Where this becomes a bit tricky (for me as a rustc dev) are the "secondary effects" of these bounds whose existence I sadly can't deny. As a matter of fact, type alias bounds do play some small roles during type checking. However, after a lot of thinking over the last two weeks I've come to the conclusion (not without second-guessing myself though) that these use cases should not trump the fact that these bounds are currently *inherently broken*. Therefore the lint `type_alias_bounds` should and will continue to flag bounds that may have subordinate uses.

The two *known* secondary effects are:

1. They may enable the use of "shorthand" associated type paths `T::Assoc` (as opposed to fully qualified paths `<T as Trait>::Assoc`) where `T` is a type param bounded by some trait `Trait` which defines that assoc ty.
2. They may affect the default lifetime of trait object types passed as a type argument to the type alias. That concept is called (trait) object lifetime default.

The second one is negligible, no question asked. The first one however is actually "kinda nice" (for writability) and comes up in practice from time to time.

So why don't I just special-case trait bounds that "define" shorthand assoc type paths as originally planned in #125709?

1. Starting to permit even a tiny subset of bounds would already be enough to send a signal to users that bounds in type aliases have been legitimized and that they can expect to see type alias bounds in the wild from now on (proliferation). This would be actively misleading and dangerous because those bounds don't behave at all like one would expect, they are *not real*[^2]!
   1. Let's take `type A<T: Trait> = T::Proj;` for example. Everywhere else in the language `T: Trait` means `T: Trait + Sized`. For type aliases, that's not the case though: `T: Trait` and `T: Trait + ?Sized` for that matter do neither mean `T: Trait + Sized` nor `T: Trait + ?Sized` (for both!). Instead, whether `T` requires `Sized` or not entirely depends on the definition of `Trait`[^2]. Namely, whether or not it is bounded by `Sized`.
   2. Given `type A<T: Trait<AssocA = ()>> = T::AssocB;`, while `X: Trait` gets checked given `A<X>` (by virtue of projection wfchecking post alias expansion[^2]), the associated type constraint `AssocA = ()` gets dropped entirely! While we could choose to warn on such cases, it would inevitably lead to a huge pile of special cases.
   3. While it's common knowledge that the body / aliased type / RHS of an (eager) type alias does not get checked for well-formedness, I'm not sure if people would realize that that extends to bounds as well. Namely, `type A<T: Trait<[u8]>> = T::Proj;` compiles even if `Trait`'s generic parameter requires `Sized`. Of course, at usage sites `[u8]: Sized` would still end up getting checked[^2], so it's not a huge problem if you have full control over `A`. However, imagine that `A` was actually part of a public API and was never used inside the defining crate (not unreasonable). In such a scenario, downstream users would be presented with an impossible to use type alias! Remember, bounds may grow arbitrarily complex and nuanced in practice.
   4. Even if we allowed trait bounds that "define" shorthand assoc type paths, we would still need to continue to warn in cases where the assoc ty comes from a supertrait despite the fact that the shorthand syntax can be used: `type A<T: Sub> = T::Assoc;` does compile given `trait Sub: Super {}` and `trait Super { type Assoc; }`. However, `A<X>` does not enforce `X: Sub`, only `X: Super`[^2]. All that to say, type alias bounds are simply not real and we shouldn't pretend they are!
   5. Summarizing the points above, we would be legitimizing bounds that are completely broken!
2. It's infeasible to implement: Due to the lack of `TypeckResults` in `ItemCtxt` (and a way to propagate it to other parts of the compiler), the resolution of type-dependent paths in non-`Body` items (most notably type aliases) is not recoverable from the HIR alone which would be necessary because the information of whether an associated type path (projection) is a shorthand is only present pre&in-HIR and doesn't survive HIR ty lowering. Of course, I could rerun parts of HIR ty lowering inside the lint `type_alias_bounds` (namely, `probe_single_ty_param_bound_for_assoc_ty` which would need to be exposed or alternatively a stripped-down version of it). This likely has a performance impact and introduces complexity. In short, the "benefits" are not worth the costs.

---

* 3rd commit: Update a diagnostic to avoid suggesting type alias bounds
* 4th commit: Flag type alias bounds even if the RHS contains inherent associated types.
  * I started to allow them at some point in the past which was not correct (see commit for details)
* 5th commit: Allow type alias bounds if the RHS contains const projections and GCEs are enabled
  * (and add a `FIXME(generic_const_exprs)` to be revisited before (M)GCE's stabilization)
  * As a matter of fact type alias bounds are enforced in this case because the contained AnonConsts do get checked for well-formedness and crucially they inherit the generics and predicates of their parent item (here: the type alias)
* Remaining commits: Improve the lint `type_alias_bounds` itself

---

Fixes #125789 (sugg diag fix).
Fixes #125709 (wontfix, acknowledgement, sugg diag applic fix).
Fixes #104918 (sugg diag applic fix).
Fixes #100270 (wontfix, acknowledgement, sugg diag applic fix).
Fixes #94398 (true fix).

r? `@compiler-errors` `@oli-obk`

[^1]: From the perspective of the trait solver.
[^2]: Given `type A<T: Trait> = T::Proj;`, the reason why the trait bound "`T: Trait`" gets *seemingly* enforced at usage sites of the type alias `A` is simply because `A<X>` gets expanded to "`<X as Trait>::Proj`" very early on and it's the *expansion* that gets checked for well-formedness, not the type alias reference.
2024-07-26 02:20:28 -04:00
Matthias Krüger
ab2dd3aeb9
Rollup merge of #127950 - nnethercote:rustfmt-skip-on-use-decls, r=cuviper
Use `#[rustfmt::skip]` on some `use` groups to prevent reordering.

`use` declarations will be reformatted in #125443. Very rarely, there is a desire to force a group of `use` declarations together in a way that auto-formatting will break up. E.g. when you want a single comment to apply to a group. #126776 dealt with all of these in the codebase, ensuring that no comments intended for multiple `use` declarations would end up in the wrong place. But some people were unhappy with it.

This commit uses `#[rustfmt::skip]` to create these custom `use` groups in an idiomatic way for a few of the cases changed in #126776. This works because rustfmt treats any `use` item annotated with `#[rustfmt::skip]` as a barrier and won't reorder other `use` items around it.

r? `@cuviper`
2024-07-26 00:57:21 +02:00
Bryanskiy
2a73553513 Support ?Trait bounds in supertraits and dyn Trait under a feature gate 2024-07-25 20:53:33 +03:00
Matthias Krüger
ae71900ef6
Rollup merge of #121364 - Urgau:unary_precedence, r=compiler-errors
Implement lint against ambiguous negative literals

This PR implements a lint against ambiguous negative literals with a literal and method calls right after it.

## `ambiguous_negative_literals`

(deny-by-default)

The `ambiguous_negative_literals` lint checks for cases that are confusing between a negative literal and a negation that's not part of the literal.

### Example

```rust,compile_fail
-1i32.abs(); // equals -1, while `(-1i32).abs()` equals 1
```

### Explanation

Method calls take precedence over unary precedence. Setting the precedence explicitly makes the code clearer and avoid potential bugs.

<details>
<summary>Old proposed lint</summary>

## `ambiguous_unary_precedence`

(deny-by-default)

The `ambiguous_unary_precedence` lint checks for use the negative unary operator with a literal and method calls.

### Example

```rust
-1i32.abs(); // equals -1, while `(-1i32).abs()` equals 1
```

### Explanation

Unary operations take precedence on binary operations and method calls take precedence over unary precedence. Setting the precedence explicitly makes the code clearer and avoid potential bugs.

</details>

-----

Note: This is a strip down version of https://github.com/rust-lang/rust/pull/117161, without the binary op precedence.

Fixes https://github.com/rust-lang/rust/issues/117155
`@rustbot` labels +I-lang-nominated
cc `@scottmcm`
r? compiler
2024-07-25 16:48:17 +02:00
León Orell Valerian Liehr
5859dff742
Update the description of lint type_alias_bounds 2024-07-23 01:49:00 +02:00
León Orell Valerian Liehr
d67b61637e
Make lint type_alias_bounds's removal sugg maybe-incorrect if the RHS contains shorthand assoc tys 2024-07-23 01:48:58 +02:00
León Orell Valerian Liehr
fdf8f024ad
Improve the impl and diag output of lint type_alias_bounds 2024-07-23 01:48:03 +02:00
León Orell Valerian Liehr
a8b3dfd253
Suppress lint type_alias_bounds for ty aliases containing const projections under GCE 2024-07-23 01:26:26 +02:00
León Orell Valerian Liehr
63a54d93be
Don't suppress lint type_alias_bounds for ty aliases containing inherent assoc tys 2024-07-23 01:26:26 +02:00
Trevor Gross
81135a015f
Rollup merge of #125990 - tbu-:pr_unsafe_env_lint_name, r=ehuss
Rename `deprecated_safe` lint to `deprecated_safe_2024`

Create a lint group `deprecated_safe` that includes `deprecated_safe_2024`.

Addresses https://github.com/rust-lang/rust/issues/124866#issuecomment-2142814375.

r? `@ehuss`
2024-07-22 11:40:19 -05:00
bors
11e57241f1 Auto merge of #127956 - tgross35:rollup-8ten7pk, r=tgross35
Rollup of 7 pull requests

Successful merges:

 - #121533 (Handle .init_array link_section specially on wasm)
 - #127825 (Migrate `macos-fat-archive`, `manual-link` and `archive-duplicate-names` `run-make` tests to rmake)
 - #127891 (Tweak suggestions when using incorrect type of enum literal)
 - #127902 (`collect_tokens_trailing_token` cleanups)
 - #127928 (Migrate `lto-smoke-c` and `link-path-order` `run-make` tests to rmake)
 - #127935 (Change `binary_asm_labels` to only fire on x86 and x86_64)
 - #127953 ([compiletest] Search *.a when getting dynamic libraries on AIX)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-07-19 11:08:02 +00:00
bors
8c3a94a1c7 Auto merge of #125915 - camelid:const-arg-refactor, r=BoxyUwU
Represent type-level consts with new-and-improved `hir::ConstArg`

### Summary

This is a step toward `min_generic_const_exprs`. We now represent all const
generic arguments using an enum that differentiates between const *paths*
(temporarily just bare const params) and arbitrary anon consts that may perform
computations. This will enable us to cleanly implement the `min_generic_const_args`
plan of allowing the use of generics in paths used as const args, while
disallowing their use in arbitrary anon consts. Here is a summary of the salient
aspects of this change:

- Add `current_def_id_parent` to `LoweringContext`

  This is needed to track anon const parents properly once we implement
  `ConstArgKind::Path` (which requires moving anon const def-creation
  outside of `DefCollector`).

- Create `hir::ConstArgKind` enum with `Path` and `Anon` variants. Use it in the
  existing `hir::ConstArg` struct, replacing the previous `hir::AnonConst` field.

- Use `ConstArg` for all instances of const args. Specifically, use it instead
  of `AnonConst` for assoc item constraints, array lengths, and const param
  defaults.

- Some `ast::AnonConst`s now have their `DefId`s created in
  rustc_ast_lowering rather than `DefCollector`. This is because in some
  cases they will end up becoming a `ConstArgKind::Path` instead, which
  has no `DefId`. We have to solve this in a hacky way where we guess
  whether the `AnonConst` could end up as a path const since we can't
  know for sure until after name resolution (`N` could refer to a free
  const or a nullary struct). If it has no chance as being a const
  param, then we create a `DefId` in `DefCollector` -- otherwise we
  decide during ast_lowering. This will have to be updated once all path
  consts use `ConstArgKind::Path`.

- We explicitly use `ConstArgHasType` for array lengths, rather than
  implicitly relying on anon const type feeding -- this is due to the
  addition of `ConstArgKind::Path`.

- Some tests have their outputs changed, but the changes are for the
  most part minor (including removing duplicate or almost-duplicate
  errors). One test now ICEs, but it is for an incomplete, unstable
  feature and is now tracked at https://github.com/rust-lang/rust/issues/127009.

### Followup items post-merge

- Use `ConstArgKind::Path` for all const paths, not just const params.
- Fix (no github dont close this issue) #127009
- If a path in generic args doesn't resolve as a type, try to resolve as a const
  instead (do this in rustc_resolve). Then remove the special-casing from
  `rustc_ast_lowering`, so that all params will automatically be lowered as
  `ConstArgKind::Path`.
- (?) Consider making `const_evaluatable_unchecked` a hard error, or at least
  trying it in crater

r? `@BoxyUwU`
2024-07-19 08:44:51 +00:00
Trevor Gross
6bdf9bd276
Rollup merge of #127935 - tgross35:binary_asm_labels-x86-only, r=estebank,Urgau
Change `binary_asm_labels` to only fire on x86 and x86_64

In <https://github.com/rust-lang/rust/pull/126922>, the `binary_asm_labels` lint was added which flags labels such as `0:` and `1:`. Before that change, LLVM was giving a confusing error on x86/x86_64 because of an incorrect interpretation.

However, targets other than x86 and x86_64 never had the error message and have not been a problem. This means that the lint was causing code that previously worked to start failing (e.g. `compiler_builtins`), rather than only providing a more clear messages where there has always been an error.

Adjust the lint to only fire on x86 and x86_64 assembly to avoid this regression.

Also update the help message.

Fixes: https://github.com/rust-lang/rust/issues/127821
2024-07-19 03:27:50 -05:00
Trevor Gross
5686720a57 Update the binary_asm_label documentation
Disable a test that now only passes on x86 and make the link point to
the new (open) LLVM bug.
2024-07-19 01:21:15 -05:00
Nicholas Nethercote
c5dadd0408 Use #[rustfmt::skip] on some use groups to prevent reordering.
`use` declarations will be reformatted in #125443. Very rarely, there is
a desire to force a group of `use` declarations together in a way that
auto-formatting will break up. E.g. when you want a single comment to
apply to a group. #126776 dealt with all of these in the codebase,
ensuring that no comments intended for multiple `use` declarations would
end up in the wrong place. But some people were unhappy with it.

This commit uses `#[rustfmt::skip]` to create these custom `use` groups
in an idiomatic way for a few of the cases changed in #126776. This
works because rustfmt treats any `use` item annotated with
`#[rustfmt::skip]` as a barrier and won't reorder other `use` items
around it.
2024-07-19 13:26:48 +10:00
Trevor Gross
8410348b1c Update the binary_asm_label message
The link pointed to a closed issue. Create a new one and point the link
to it.

Also add a help message to hint what change the user could make.

Fixes: https://github.com/rust-lang/rust/issues/127821
2024-07-18 17:00:43 -04:00
Trevor Gross
9387a7523e Change binary_asm_labels to only fire on x86 and x86_64
In <https://github.com/rust-lang/rust/pull/126922>, the
`binary_asm_labels` lint was added which flags labels such as `0:` and
`1:`. Before that change, LLVM was giving a confusing error on
x86/x86_64 because of an incorrect interpretation.

However, targets other than x86 and x86_64 never had the error message
and have not been a problem. This means that the lint was causing code
that previously worked to start failing (e.g. `compiler_builtins`),
rather than only providing a more clear messages where there has always
been an error.

Adjust the lint to only fire on x86 and x86_64 assembly to avoid this
regression.
2024-07-18 15:00:56 -05:00
Matthias Krüger
4ad2c99b6d
Rollup merge of #127854 - fmease:glob-import-type_ir_inherent-lint, r=compiler-errors
Add internal lint for detecting non-glob imports of `rustc_type_ir::inherent`

https://github.com/rust-lang/rust/pull/127627#issuecomment-2225295951

r? compiler-errors
2024-07-18 18:10:16 +02:00
León Orell Valerian Liehr
2507301de0
Add internal lint for detecting non-glob imports of rustc_type_ir::inherent 2024-07-18 13:03:26 +02:00
Tobias Bucher
bf96c56e84 Rename deprecated_safe lint to deprecated_safe_2024
Create a lint group `deprecated_safe` that includes
`deprecated_safe_2024`.

Addresses https://github.com/rust-lang/rust/issues/124866#issuecomment-2142814375.
2024-07-17 14:39:56 +02:00
Noah Lev
11b144aa98 hir: Create hir::ConstArgKind enum
This will allow lowering const params to a dedicated enum variant, rather
than to an `AnonConst` that is later examined during `ty` lowering.
2024-07-16 19:27:28 -07:00
Nicholas Nethercote
75b6ec9800 Avoid comments that describe multiple use items.
There are some comments describing multiple subsequent `use` items. When
the big `use` reformatting happens some of these `use` items will be
reordered, possibly moving them away from the comment. With this
additional level of formatting it's not really feasible to have comments
of this type. This commit removes them in various ways:

- merging separate `use` items when appropriate;

- inserting blank lines between the comment and the first `use` item;

- outright deletion (for comments that are relatively low-value);

- adding a separate "top-level" comment.

We also entirely skip formatting for four library files that contain
nothing but `pub use` re-exports, where reordering would be painful.
2024-07-17 08:02:46 +10:00
Jubilee
4bfc10617a
Rollup merge of #127631 - compiler-errors:yeet-fully-norm, r=lcnr
Remove `fully_normalize`

Yeet this function and replace it w/ some `ObligationCtxt` instead. It wasn't called very often anyways.

r? lcnr
2024-07-12 13:47:09 -07:00
Jubilee
2e0591b1e9
Rollup merge of #127535 - spastorino:unsafe_code-unsafe_extern_blocks, r=oli-obk
Fire unsafe_code lint on unsafe extern blocks

Fixes #126738
2024-07-12 13:47:08 -07:00
Jubilee
fc0136e4f4
Rollup merge of #126922 - asquared31415:asm_binary_label, r=estebank
add lint for inline asm labels that look like binary

fixes #94426

Due to a bug/feature in LLVM, labels composed of only the digits `0` and `1` can sometimes be confused with binary literals, even if a binary literal would not be valid in that position.

This PR adds detection for such labels and also as a drive-by change, adds a note to cases such as `asm!(include_str!("file"))` that the label that it found came from an expansion of a macro, it wasn't found in the source code.

I expect this PR to upset some people that were using labels `0:` or `1:` without issue because they never hit the case where LLVM got it wrong, but adding a heuristic to the lint to prevent this is not feasible - it would involve writing a whole assembly parser for every target that we have assembly support for.

[zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bweekly.5D.202024-06-20/near/445870628)

r? ``@estebank``
2024-07-12 13:47:05 -07:00
Michael Goulet
2c8bbeebf1 Remove fully_normalize 2024-07-11 19:15:04 -04:00
bors
9b0043095a Auto merge of #127097 - compiler-errors:async-closure-lint, r=oli-obk
Implement simple, unstable lint to suggest turning closure-of-async-block into async-closure

We want to eventually suggest people to turn `|| async {}` to `async || {}`. This begins doing that. It's a pretty rudimentary lint, but I wanted to get something down so I wouldn't lose the code.

Tracking:
* #62290
2024-07-11 06:59:10 +00:00
Urgau
de560c3065 Implement ambiguous_negative_literals lint 2024-07-11 00:46:47 +02:00
bors
649feb9c1a Auto merge of #127549 - jhpratt:rollup-o1mbmhr, r=jhpratt
Rollup of 8 pull requests

Successful merges:

 - #124211 (Bump `elided_lifetimes_in_associated_constant` to deny)
 - #125627 (migration lint for `expr2024` for the edition 2024)
 - #127091 (impl FusedIterator and a size hint for the error sources iter)
 - #127461 (Fixup failing fuchsia tests)
 - #127484 (`#[doc(alias)]`'s doc: say that ASCII spaces are allowed)
 - #127508 (small search graph refactor)
 - #127521 (Remove spastorino from SMIR)
 - #127532 (documentation: update cmake version)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-07-10 06:35:04 +00:00
Jacob Pratt
21a0e86234
Rollup merge of #125627 - vincenzopalazzo:macros/cargo-fix-expr2024, r=compiler-errors,eholk
migration lint for `expr2024` for the edition 2024

This is adding a migration lint for the current (in the 2021 edition and previous)
to move expr to expr_2021 from expr

Issue https://github.com/rust-lang/rust/issues/123742

I created also a repository to test out the migration https://github.com/vincenzopalazzo/expr2024-cargo-fix-migration

Co-Developed-by: ``@eholk``
2024-07-10 00:37:10 -04:00
bors
7caf6726db Auto merge of #127496 - tgross35:f16-f128-pattern-fixme, r=Nadrieril
Update `f16`/`f128` FIXMEs that needed `(NEG_)INFINITY`

Just a small fix to the pattern matching tests now that we can. Also contains a small unrelated comment tweak.
2024-07-10 04:20:32 +00:00
Santiago Pastorino
a3ef94e80e
Fire unsafe_code lint on unsafe extern blocks 2024-07-09 17:35:51 -03:00
Vincenzo Palazzo
25637e2c8e Adds expr_2024 migration lit
This is adding a migration lint for the current (in the 2021 edition and previous)
to move expr to expr_2021 from expr

Co-Developed-by: Eric Holk
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
2024-07-09 17:41:13 +00:00
asquared31415
87856c4461 add lint for inline asm labels that look like binary 2024-07-09 01:23:49 +00:00
Trevor Gross
96a791662a Update a f16/f128 FIXME to be more accurate 2024-07-08 18:55:26 -04:00
Michael Goulet
fe4c995ccb Move trait selection error reporting to its own top-level module 2024-07-08 16:04:47 -04:00
Michael Goulet
58aad3c72c iter_identity is a better name 2024-07-07 00:12:35 -04:00
Michael Goulet
865518d1f2
Rollup merge of #127221 - Urgau:check-cfg-std-diag, r=pnkfelix
Improve well known value check-cfg diagnostic for the standard library

This PR adjust the current logic for hidding the rustc/Cargo suggestion to add a value to a well-known name to exclude the standard library and rustc crates.

This is done in order to improve the contributor experience, in particular when adding a new target, which often requires adding some cfgs like `target_os` which may not be available yet in stage0.

<details>

The diagnostic code would look like this.

```text
error: unexpected `cfg` condition value: `blable`
   --> library/core/src/lib.rs:369:7
    |
369 | #[cfg(target_os = "blable")]
    |       ^^^^^^^^^^^^^^^^^^^^
    |
    = note: expected values for `target_os` are: `aix`, `android`, `cuda`, `dragonfly`, `emscripten`, `espidf`, `freebsd`, `fuchsia`, `haiku`, `hermit`, `horizon`, `hurd`, `illumos`, `ios`, `l4re`, `linux`, `macos`, `netbsd`, `none`, `nto`, `openbsd`, `psp`, `redox`, `solaris`, `solid_asp3`, `teeos`, `tvos`, `uefi`, `unknown`, `visionos`, `vita`, `vxworks`, `wasi`, `watchos`, and `windows` and 2 more
    = help: consider using a Cargo feature instead
    = help: or consider adding in `Cargo.toml` the `check-cfg` lint config for the lint:
             [lints.rust]
             unexpected_cfgs = { level = "warn", check-cfg = ['cfg(target_os, values("blable"))'] }
    = help: or consider adding `println!("cargo::rustc-check-cfg=cfg(target_os, values(\"blable\"))");` to the top of the `build.rs`
    = note: see <https://doc.rust-lang.org/nightly/rustc/check-cfg/cargo-specifics.html> for more information about checking conditional configuration
    = note: `-D unexpected-cfgs` implied by `-D warnings`
    = help: to override `-D warnings` add `#[allow(unexpected_cfgs)]`
```

</details>
2024-07-05 20:49:32 -04:00
Michael Goulet
b1059ccda2 Instance::resolve -> Instance::try_resolve, and other nits 2024-07-02 17:28:03 -04:00
Urgau
9e12d919c3 Improve well known value check-cfg diagnostic for the standard library 2024-07-01 23:03:36 +02:00
Matthias Krüger
6f5765599e
Rollup merge of #126018 - nnethercote:rm-box_pointers-lint, r=lcnr
Remove the `box_pointers` lint.

As the comment says, this lint "is mostly historical, and not particularly useful". It's not worth keeping it around.

r? ``@estebank``
2024-06-30 18:25:31 +02:00
Matthias Krüger
e9d5a2f45f
Rollup merge of #127045 - compiler-errors:explicit, r=oli-obk
Rename `super_predicates_of` and similar queries to `explicit_*` to note that they're not elaborated

Rename:
* `super_predicates_of` -> `explicit_super_predicates_of`
* `implied_predicates_of` -> `explicit_implied_predicates_of`
* `supertraits_containing_assoc_item` -> `explicit_supertraits_containing_assoc_item`

This makes it clearer that, unlike (for example) [`TyCtxt::super_traits_of`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.super_traits_of), we don't automatically elaborate this set of predicates.

r? ``@lcnr`` or ``@oli-obk`` or someone from t-types idc
2024-06-29 09:14:57 +02:00
Michael Goulet
acc13e29d1 Make it into a structured suggestion, maybe-incorrect 2024-06-28 20:16:35 -04:00
Michael Goulet
d526adad25 Basic lint detecting closure-returning-async-block 2024-06-28 20:16:35 -04:00
Michael Goulet
6f3ad0a40b Only require symbol name for @feature_gate 2024-06-28 18:33:31 -04:00
Matthias Krüger
3f560afde5
Rollup merge of #127015 - Urgau:non_local_def-tmp-allow, r=lqd
Switch back `non_local_definitions` lint to allow-by-default

This PR switch back (again) the `non_local_definitions` lint to allow-by-default as T-lang is requesting some (major) changes in the lint inner workings in https://github.com/rust-lang/rust/issues/126768#issuecomment-2192634762.

This PR will need to be beta-backported, as the lint is currently warn-by-default in beta.
2024-06-28 22:04:16 +02:00
Michael Goulet
81c2c57519 Make queries more explicit 2024-06-27 12:03:57 -04:00
Urgau
0c0dfb88ee Switch back non_local_definitions lint to allow-by-default
as request T-lang is requesting some major changes in the lint inner
workings in #126768#issuecomment-2192634762
2024-06-27 08:05:07 +02:00
Nicholas Nethercote
c053e8939b Remove the box_pointers lint.
As the comment says, this lint "is mostly historical, and not
particularly useful". It's not worth keeping it around.
2024-06-27 08:55:28 +10:00
xFrednet
8b14e23dce
RFC 2383: Stabilize lint_reasons 🎉 2024-06-25 17:22:22 +02:00
bors
d929a42a66 Auto merge of #125741 - petrochenkov:atvisord, r=davidtwco
ast: Standardize visiting order for attributes and node IDs

This should only affect `macro_rules` scopes and order of diagnostics.

Also add a deprecation lint for `macro_rules` called outside of their scope, like in https://github.com/rust-lang/rust/issues/124535.
2024-06-25 11:48:14 +00:00
Michael Goulet
f26cc349d9 Split out IntoIterator and non-Iterator constructors for AliasTy/AliasTerm/TraitRef/projection 2024-06-24 11:28:21 -04:00
Vadim Petrochenkov
c4c7859e40 resolve: Implement a lint for out-of-scope use of macro_rules 2024-06-24 17:12:08 +03:00
carbotaniuman
a23917cfd0 Add hard error and migration lint for unsafe attrs 2024-06-23 19:02:14 -05:00
Michael Goulet
ffd72b1700 Fix remaining cases 2024-06-21 19:00:18 -04:00
Michael Goulet
db638ab968 Rename a bunch of things 2024-06-21 12:32:05 -04:00
Manish Goregaokar
e8a9af9ad9 Clarify that anonymous consts still do introduce a new scope 2024-06-19 18:34:15 -07:00
许杰友 Jieyou Xu (Joe)
081cc5cc2d
Rollup merge of #126422 - Urgau:doctest-impl-non-local-def, r=fmease
Suggest using a standalone doctest for non-local impl defs

This PR tweaks the lint output of the `non_local_definitions` lint to suggest using a standalone doctest instead of a moving the `impl` def to an impossible place as was already done with `macro_rules!` case in https://github.com/rust-lang/rust/pull/124568.

Fixes #126339
r? ```@fmease```
2024-06-19 01:51:39 +01:00
Oli Scherer
3f34196839 Remove redundant argument from subdiagnostic method 2024-06-18 15:42:11 +00:00
Oli Scherer
7ba82d61eb Use a dedicated type instead of a reference for the diagnostic context
This paves the way for tracking more state (e.g. error tainting) in the diagnostic context handle
2024-06-18 15:42:11 +00:00
Michael Goulet
b1efe1ab5d Rework precise capturing syntax 2024-06-17 22:35:25 -04:00
许杰友 Jieyou Xu (Joe)
23b936f981
Rollup merge of #125258 - compiler-errors:static-if-no-lt, r=nnethercote
Resolve elided lifetimes in assoc const to static if no other lifetimes are in scope

Implements the change to elided lifetime resolution in *associated consts* subject to FCP here: https://github.com/rust-lang/rust/issues/125190#issue-2301532282

Specifically, walk the enclosing lifetime ribs in an associated const, and if we find no other lifetimes, then resolve to `'static`.

Also make it work for traits, but don't lint -- just give a hard error in that case.
2024-06-17 04:53:54 +01:00
Kalle Wachsmuth
dfe69f7259
boxed_slice_into_iter: tiny doc correction 2024-06-16 20:57:48 +02:00
Urgau
94c282197d Also simplify macro_rules doctest code 2024-06-15 13:00:54 +02:00
Urgau
ab0e72781f Suggest standalone doctest for non-local impl defs 2024-06-15 13:00:53 +02:00
bors
1d1356d0f6 Auto merge of #125722 - Urgau:non_local_defs-macro-to-change, r=estebank
Indicate in `non_local_defs` lint that the macro needs to change

This PR adds a note to indicate that the macro needs to change in the `non_local_definitions` lint output.

Address https://github.com/rust-lang/rust/pull/125089#discussion_r1616311862
Fixes #125681
r? `@estebank`
2024-06-15 08:50:44 +00:00
Michael Goulet
93ff86ed7c Use is_lang_item more aggressively 2024-06-14 16:54:29 -04:00
Michael Goulet
4f97ab54c4 Resolve elided lifetimes in assoc const to static if no other lifetimes are in scope 2024-06-14 11:05:35 -04:00
bors
c25ac9d6cc Auto merge of #126273 - pietroalbini:pa-bootstrap-update, r=Mark-Simulacrum
Bump stage0 to 1.80.0

r? `@Mark-Simulacrum`
2024-06-12 18:15:32 +00:00
bors
bbe9a9c20b Auto merge of #126319 - workingjubilee:rollup-lendnud, r=workingjubilee
Rollup of 16 pull requests

Successful merges:

 - #123374 (DOC: Add FFI example for slice::from_raw_parts())
 - #124514 (Recommend to never display zero disambiguators when demangling v0 symbols)
 - #125978 (Cleanup: HIR ty lowering: Consolidate the places that do assoc item probing & access checking)
 - #125980 (Nvptx remove direct passmode)
 - #126187 (For E0277 suggest adding `Result` return type for function when using QuestionMark `?` in the body.)
 - #126210 (docs(core): make more const_ptr doctests assert instead of printing)
 - #126249 (Simplify `[T; N]::try_map` signature)
 - #126256 (Add {{target}} substitution to compiletest)
 - #126263 (Make issue-122805.rs big endian compatible)
 - #126281 (set_env: State the conclusion upfront)
 - #126286 (Make `storage-live.rs` robust against rustc internal changes.)
 - #126287 (Update a cranelift patch file for formatting changes.)
 - #126301 (Use `tidy` to sort crate attributes for all compiler crates.)
 - #126305 (Make PathBuf less Ok with adding UTF-16 then `into_string`)
 - #126310 (Migrate run make prefer rlib)
 - #126314 (fix RELEASES: we do not support upcasting to auto traits)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-06-12 11:10:50 +00:00
Oli Scherer
85f2ecab57 Add a fn main() {} to a doctest to prevent the test from being wrapped in a fn main() {} body 2024-06-12 08:53:59 +00:00
Nicholas Nethercote
75b164d836 Use tidy to sort crate attributes for all compiler crates.
We already do this for a number of crates, e.g. `rustc_middle`,
`rustc_span`, `rustc_metadata`, `rustc_span`, `rustc_errors`.

For the ones we don't, in many cases the attributes are a mess.
- There is no consistency about order of attribute kinds (e.g.
  `allow`/`deny`/`feature`).
- Within attribute kind groups (e.g. the `feature` attributes),
  sometimes the order is alphabetical, and sometimes there is no
  particular order.
- Sometimes the attributes of a particular kind aren't even grouped
  all together, e.g. there might be a `feature`, then an `allow`, then
  another `feature`.

This commit extends the existing sorting to all compiler crates,
increasing consistency. If any new attribute line is added there is now
only one place it can go -- no need for arbitrary decisions.

Exceptions:
- `rustc_log`, `rustc_next_trait_solver` and `rustc_type_ir_macros`,
  because they have no crate attributes.
- `rustc_codegen_gcc`, because it's quasi-external to rustc (e.g. it's
  ignored in `rustfmt.toml`).
2024-06-12 15:49:10 +10:00
许杰友 Jieyou Xu (Joe)
ecc0046fb6
Rollup merge of #125659 - tbu-:pr_rm_isize, r=pnkfelix
Remove usage of `isize` in example

`isize` is a rare integer type, replace it with a more common one.
2024-06-11 21:27:45 +01:00
Pietro Albini
be9e27e490
replace version placeholder 2024-06-11 16:52:02 +02:00
许杰友 Jieyou Xu (Joe)
81ff9b5770
Rollup merge of #125913 - fmease:early-lints-spruce-up-some-diags, r=Nadrieril
Spruce up the diagnostics of some early lints

Implement the various "*(note to myself) in a follow-up PR we should turn parts of this message into a subdiagnostic (help msg or even struct sugg)*" drive-by comments I left in #124417 during my review.

For context, before #124417, only a few early lints touched/decorated/customized their diagnostic because the former API made it a bit awkward. Likely because of that, things that should've been subdiagnostics were just crammed into the primary message. This PR rectifies this.
2024-06-11 09:14:34 +01:00
Jubilee
6a42df7517
Rollup merge of #126040 - Urgau:unreachable_pub-fields-less, r=petrochenkov
Don't warn on fields in the `unreachable_pub` lint

This PR restrict the `unreachable_pub` lint by not linting on `pub` fields of `pub(restricted)` structs and unions. This is done because that can quickly clutter the code for an uncertain value, in particular since the "real" visibility is defined by the parent (the struct it-self).

This is meant to address one of the last concern of the `unreachable_pub` lint.

r? ``@petrochenkov``
2024-06-06 21:10:10 -07:00
Urgau
89d86ae5bd Don't warn on fields in the unreachable_pub lint 2024-06-06 19:07:05 +02:00
bors
2d28b6384e Auto merge of #124482 - spastorino:unsafe-extern-blocks, r=oli-obk
Unsafe extern blocks

This implements RFC 3484.

Tracking issue #123743 and RFC https://github.com/rust-lang/rfcs/pull/3484

This is better reviewed commit by commit.
2024-06-06 08:14:58 +00:00
Santiago Pastorino
1afc7d716c
Make MISSING_UNSAFE_ON_EXTERN lint emit future compat info with suggestion to prepend unsafe 2024-06-05 09:36:01 -03:00
Guillaume Gomez
fa96e2cb4f
Rollup merge of #125596 - nnethercote:rental-hard-error, r=estebank
Convert `proc_macro_back_compat` lint to an unconditional error.

We still check for the `rental`/`allsorts-rental` crates. But now if they are detected we just emit a fatal error, instead of emitting a warning and providing alternative behaviour.

The original "hack" implementing alternative behaviour was added in #73345.

The lint was added in #83127.

The tracking issue is #83125.

The direct motivation for the change is that providing the alternative behaviour is interfering with #125174 and follow-on work.

r? ``@estebank``
2024-06-04 21:41:33 +02:00
Santiago Pastorino
2a377122dd
Handle safety keyword for extern block inner items 2024-06-04 14:19:42 -03:00
Santiago Pastorino
3ba8de0b60
Make extern blocks without unsafe warn in edition 2024 2024-06-04 14:19:42 -03:00
许杰友 Jieyou Xu (Joe)
b477f89041
Rollup merge of #125750 - compiler-errors:expect, r=lcnr
Align `Term` methods with `GenericArg` methods, add `Term::expect_*`

* `Term::ty` -> `Term::as_type`.
* `Term::ct` -> `Term::as_const`.
* Adds `Term::expect_type` and `Term::expect_const`, and uses them in favor of `.ty().unwrap()`, etc.

I could also shorten these to `as_ty` and then do `GenericArg::as_ty` as well, but I do think the `as_` is important to signal that this is a conversion method, and not a getter, like `Const::ty` is.

r? types
2024-06-04 08:25:48 +01:00
Michael Goulet
273b990554 Align Term methods with GenericArg methods 2024-06-03 20:36:27 -04:00
Michael Goulet
511f1cf7c8 check_is_object_safe -> is_object_safe 2024-06-03 09:49:30 -04:00
León Orell Valerian Liehr
b2949ff911
Spruce up the diagnostics of some early lints 2024-06-03 07:25:32 +02:00
Nicholas Nethercote
32c8a12854 Tweak CheckLintNameResult::Tool.
It has a clumsy type, with repeated `&'a [LintId]`, and sometimes
requires an empty string that isn't used in the `Err`+`None` case.

This commit splits it into two variants.
2024-06-03 09:02:49 +10:00
Nicholas Nethercote
d070e89230 Reduce some pub exposure. 2024-06-03 08:44:33 +10:00
Nicholas Nethercote
22ca74f2b0 Fix up comments.
Wrap overly long ones, etc.
2024-06-03 08:44:33 +10:00
bors
d43930dab3 Auto merge of #125711 - oli-obk:const_block_ice2, r=Nadrieril
Make `body_owned_by` return the `Body` instead of just the `BodyId`

fixes #125677

Almost all `body_owned_by` callers immediately called `body`, too, so just return `Body` directly.

This makes the inline-const query feeding more robust, as all calls to `body_owned_by` will now yield a body for inline consts, too.

I have not yet figured out a good way to make `tcx.hir().body()` return an inline-const body, but that can be done as a follow-up
2024-05-30 08:00:11 +00:00
Urgau
b5d4867936 non_local_defs: move cargo update suggestion upper 2024-05-29 17:03:11 +02:00
Urgau
c4c8bda689 non_local_defs: indicate that the macro needs to change
aaa
2024-05-29 17:03:11 +02:00
surechen
9d1ed80a8a Change lint_dropping_copy_types to use UseLetUnderscoreIgnoreSuggestion as suggestion. 2024-05-29 18:09:20 +08:00
Oli Scherer
ceb45d5519 Don't require visit_body to take a lifetime that must outlive the function call 2024-05-29 10:04:08 +00:00
surechen
ac736d6d88 Let lint_forgetting_references give the suggestion if possible 2024-05-29 17:40:34 +08:00
surechen
d7f0d1f564 Let lint_forgetting_copy_types give the suggestion if possible. 2024-05-29 16:53:37 +08:00
surechen
ca68c93135 Let lint_dropping_references give the suggestion if possible. 2024-05-29 16:53:28 +08:00
bors
5870f1ccbb Auto merge of #125433 - surechen:fix_125189, r=Urgau
A small diagnostic improvement for dropping_copy_types

For a value `m`  which implements `Copy` trait, `drop(m);` does nothing.
We now suggest user to ignore it by a abstract and general note: `let _ = ...`.
I think we can give a clearer note here: `let _ = m;`

fixes #125189

<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.

This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using

    r​? <reviewer name>
-->
2024-05-29 06:14:05 +00:00
Tobias Bucher
eb0ed28ced Remove usage of isize in example
`isize` is a rare integer type, replace it with a more common one.
2024-05-28 15:31:26 +02:00
Nicholas Nethercote
cf0c2c7333 Convert proc_macro_back_compat lint to an unconditional error.
We still check for the `rental`/`allsorts-rental` crates. But now if
they are detected we just emit a fatal error, instead of emitting a
warning and providing alternative behaviour.

The original "hack" implementing alternative behaviour was added
in #73345.

The lint was added in #83127.

The tracking issue is #83125.

The direct motivation for the change is that providing the alternative
behaviour is interfering with #125174 and follow-on work.
2024-05-28 08:15:15 +10:00
Urgau
c7d300442f non_local_defs: point the parent item when appropriate 2024-05-27 23:59:18 +02:00
Urgau
98273ec612 non_local_defs: point to Self and Trait to give more context 2024-05-27 23:59:18 +02:00
Urgau
b71952904d non_local_defs: suggest removing leading ref/ptr to make the impl local 2024-05-27 23:59:18 +02:00
Urgau
ab23fd8dea non_local_defs: improve main without a trait note 2024-05-27 23:59:18 +02:00
Urgau
d3dfe14b53 non_local_defs: be more precise about what needs to be moved 2024-05-27 23:59:18 +02:00
Urgau
402580bcd5 non_local_defs: improve exception note for impl and macro_rules!
- Remove wrong exception text for non-local macro_rules!
 - Simplify anonymous const exception note
2024-05-27 23:59:18 +02:00
Urgau
22095fbd8d non_local_defs: use labels to indicate what may need to be moved 2024-05-27 23:58:55 +02:00
Urgau
26b873d030 non_local_defs: use span of the impl def and not the impl block 2024-05-27 23:58:55 +02:00
Urgau
de1c122950 non_local_defs: improve some notes around trait, bounds, consts
- Restrict const-anon exception diag to relevant places
 - Invoke bounds (and type-inference) in non_local_defs
 - Specialize diagnostic for impl without Trait
2024-05-27 23:58:55 +02:00
Urgau
06c6a2d9d6 non_local_defs: switch to more friendly primary message 2024-05-27 23:58:55 +02:00
Urgau
5ad4ad7aee non_local_defs: move out from #[derive(LintDiagnostic)] to manual impl 2024-05-27 23:58:55 +02:00
Guillaume Gomez
a9c125f864
Rollup merge of #125597 - compiler-errors:early-binder, r=jackh726
Uplift `EarlyBinder` into `rustc_type_ir`

We also need to give `EarlyBinder` a `'tcx` param, so that we can carry the `Interner` in the `EarlyBinder` too. This is necessary because otherwise we have an unconstrained `I: Interner` parameter in many of the `EarlyBinder`'s inherent impls.

I also generally think that this is desirable to have, in case we later want to track some state in the `EarlyBinder`.

r? lcnr
2024-05-27 13:10:36 +02:00
bors
b582f807fa Auto merge of #125410 - fmease:adj-lint-diag-api, r=nnethercote
[perf] Delay the construction of early lint diag structs

Attacks some of the perf regressions from https://github.com/rust-lang/rust/pull/124417#issuecomment-2123700666.

See individual commits for details. The first three commits are not strictly necessary.
However, the 2nd one (06bc4fc671, *Remove `LintDiagnostic::msg`*) makes the main change way nicer to implement.
It's also pretty sweet on its own if I may say so myself.
2024-05-27 08:44:12 +00:00
bors
fec98b3bbc Auto merge of #125468 - BoxyUwU:remove_defid_from_regionparam, r=compiler-errors
Remove `DefId` from `EarlyParamRegion`

Currently we represent usages of `Region` parameters via the `ReEarlyParam` or `ReLateParam` variants. The `ReEarlyParam` is effectively equivalent to `TyKind::Param` and `ConstKind::Param` (i.e. it stores a `Symbol` and a `u32` index) however it also stores a `DefId` for the definition of the lifetime parameter.

This was used in roughly two places:
- Borrowck diagnostics instead of threading the appropriate `body_id` down to relevant locations. Interestingly there were already some places that had to pass down a `DefId` manually.
- Some opaque type checking logic was using the `DefId` field to track captured lifetimes

I've split this PR up into a commit for generate rote changes to diagnostics code to pass around a `DefId` manually everywhere, and another commit for the opaque type related changes which likely require more careful review as they might change the semantics of lints/errors.

Instead of manually passing the `DefId` around everywhere I previously tried to bundle it in with `TypeErrCtxt` but ran into issues with some call sites of `infcx.err_ctxt` being unable to provide a `DefId`, particularly places involved with trait solving and normalization. It might be worth investigating adding some new wrapper type to pass this around everywhere but I think this might be acceptable for now.

This pr also has the effect of reducing the size of `EarlyParamRegion` from 16 bytes -> 8 bytes. I wouldn't expect this to have any direct performance improvement however, other variants of `RegionKind` over `8` bytes are all because they contain a `BoundRegionKind` which is, as far as I know, mostly there for diagnostics. If we're ever able to remove this it would shrink the `RegionKind` type from `24` bytes to `12` (and with clever bit packing we might be able to get it to `8` bytes). I am curious what the performance impact would be of removing interning of `Region`'s if we ever manage to shrink `RegionKind` that much.

Sidenote: by removing the `DefId` the `Debug` output for `Region` has gotten significantly nicer. As an example see this opaque type debug print before vs after this PR:
`Opaque(DefId(0:13 ~ impl_trait_captures[aeb9]::foo::{opaque#0}), [DefId(0:9 ~ impl_trait_captures[aeb9]::foo::'a)_'a/#0, T, DefId(0:9 ~ impl_trait_captures[aeb9]::foo::'a)_'a/#0])`
`Opaque(DefId(0:13 ~ impl_trait_captures[aeb9]::foo::{opaque#0}), ['a/#0, T, 'a/#0])`

r? `@compiler-errors` (I would like someone who understands the opaque type setup to atleast review the type system commit, but the rest is likely reviewable by anyone)
2024-05-27 06:36:57 +00:00
Michael Goulet
bbcdb4fd3e Give EarlyBinder a tcx parameter
We are gonna need it to uplift EarlyBinder
2024-05-26 20:04:05 -04:00
bors
5fe5543502 Auto merge of #124661 - RalfJung:only-structural-consts-in-patterns, r=pnkfelix
Turn remaining non-structural-const-in-pattern lints into hard errors

This completes the implementation of https://github.com/rust-lang/rust/issues/120362 by turning our remaining future-compat lints into hard errors: indirect_structural_match and pointer_structural_match.

They have been future-compat lints for a while (indirect_structural_match for many years, pointer_structural_match since Rust 1.75 (released Dec 28, 2023)), and have shown up in dependency breakage reports since Rust 1.78 (just released on May 2, 2024). I don't expect a lot of code will still depend on them, but we will of course do a crater run.

A lot of cleanup is now possible in const_to_pat, but that is deferred to a later PR.

Fixes https://github.com/rust-lang/rust/issues/70861
2024-05-26 07:55:47 +00:00
Boxy
ed8e436916 move generics_of call outside of iter 2024-05-24 20:15:54 +01:00
Boxy
fe2d7794ca Remove DefId from EarlyParamRegion (tedium/diagnostics) 2024-05-24 18:06:53 +01:00
Boxy
bd6344d829 Remove DefId from EarlyParamRegion (type system) 2024-05-24 17:33:48 +01:00
Matthias Krüger
eb6297eb6f
Rollup merge of #125477 - nnethercote:missed-rustfmt, r=compiler-errors
Run rustfmt on files that need it.

Somehow these files aren't properly formatted. By default `x fmt` and `x tidy` only check files that have changed against master, so if an ill-formatted file somehow slips in it can stay that way as long as it doesn't get modified(?)

I found these when I ran `x fmt` explicitly on every `.rs` file in the repo, while working on
https://github.com/rust-lang/compiler-team/issues/750.
2024-05-24 17:48:03 +02:00
surechen
09c8e39adb A small diagnostic improvement for dropping_copy_types
fixes #125189
2024-05-24 19:31:57 +08:00
Nicholas Nethercote
c1ac4a2f28 Run rustfmt on files that need it.
Somehow these files aren't properly formatted. By default `x fmt` and `x
tidy` only check files that have changed against master, so if an
ill-formatted file somehow slips in it can stay that way as long as it
doesn't get modified(?)

I found these when I ran `x fmt` explicitly on every `.rs` file in the
repo, while working on
https://github.com/rust-lang/compiler-team/issues/750.
2024-05-24 15:17:21 +10:00
bors
7601adcc76 Auto merge of #125463 - GuillaumeGomez:rollup-287wx4y, r=GuillaumeGomez
Rollup of 6 pull requests

Successful merges:

 - #125263 (rust-lld: fallback to rustc's sysroot if there's no path to the linker in the target sysroot)
 - #125345 (rustc_codegen_llvm: add support for writing summary bitcode)
 - #125362 (Actually use TAIT instead of emulating it)
 - #125412 (Don't suggest adding the unexpected cfgs to the build-script it-self)
 - #125445 (Migrate `run-make/rustdoc-with-short-out-dir-option` to `rmake.rs`)
 - #125452 (Cleanup check-cfg handling in core and std)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-05-24 03:04:06 +00:00
Guillaume Gomez
56427d3372
Rollup merge of #125412 - Urgau:check-cfg-less-build-rs, r=wesleywiser
Don't suggest adding the unexpected cfgs to the build-script it-self

This PR adds a check to avoid suggesting to add the unexpected cfgs inside the build-script when building the build-script it-self, as it won't have any effect, since build-scripts applies to their descended target.

Fixes #125368
2024-05-23 23:39:28 +02:00
bors
8679004993 Auto merge of #125434 - nnethercote:rm-more-extern-tracing, r=jackh726
Remove more `#[macro_use] extern crate tracing`

Because explicit importing of macros via use items is nicer (more standard and readable) than implicit importing via `#[macro_use]`. Continuing the work from #124511 and #124914.

r? `@jackh726`
2024-05-23 21:36:54 +00:00
Matthias Krüger
e713b2a00c
Rollup merge of #125416 - compiler-errors:param-env-missing-copy, r=lcnr
Use correct param-env in `MissingCopyImplementations`

We shouldn't assume the param-env is empty for this lint, since although we check the struct has no parameters, there still may be trivial where-clauses.

fixes #125394
2024-05-23 14:09:25 +02:00
Matthias Krüger
337987bf63
Rollup merge of #125210 - fmease:fix-up-some-diags, r=davidtwco
Cleanup: Fix up some diagnostics

Several diagnostics contained their error code inside their primary message which is no bueno.
This PR moves them out of the message and turns them into structured error codes.

Also fixes another occurrence of `->` after a selector in a Fluent message which is not correct. I've fixed two other instances of this issue in #104345 (2022) but didn't update all instances as I've noted here: https://github.com/rust-lang/rust/pull/104345#issuecomment-1312705977 (“the future is now!”).
2024-05-23 14:09:24 +02:00
Nicholas Nethercote
c7da1a5bb8 Remove #[macro_use] extern crate tracing from rustc_lint. 2024-05-23 18:02:17 +10:00
Matthias Krüger
4af1c31fcf
Rollup merge of #125156 - zachs18:for_loops_over_fallibles_behind_refs, r=Nilstrieb
Expand `for_loops_over_fallibles` lint to lint on fallibles behind references.

Extends the scope of the (warn-by-default) lint `for_loops_over_fallibles` from just `for _ in x` where `x: Option<_>/Result<_, _>` to also cover `x: &(mut) Option<_>/Result<_>`

```rs
fn main() {
    // Current lints
    for _ in Some(42) {}
    for _ in Ok::<_, i32>(42) {}

    // New lints
    for _ in &Some(42) {}
    for _ in &mut Some(42) {}
    for _ in &Ok::<_, i32>(42) {}
    for _ in &mut Ok::<_, i32>(42) {}

    // Should not lint
    for _ in Some(42).into_iter() {}
    for _ in Some(42).iter() {}
    for _ in Some(42).iter_mut() {}
    for _ in Ok::<_, i32>(42).into_iter() {}
    for _ in Ok::<_, i32>(42).iter() {}
    for _ in Ok::<_, i32>(42).iter_mut() {}
}
```

<details><summary><code>cargo build</code> diff</summary>

```diff
diff --git a/old.out b/new.out
index 84215aa..ca195a7 100644
--- a/old.out
+++ b/new.out
`@@` -1,33 +1,93 `@@`
 warning: for loop over an `Option`. This is more readably written as an `if let` statement
  --> src/main.rs:3:14
   |
 3 |     for _ in Some(42) {}
   |              ^^^^^^^^
   |
   = note: `#[warn(for_loops_over_fallibles)]` on by default
 help: to check pattern in a loop use `while let`
   |
 3 |     while let Some(_) = Some(42) {}
   |     ~~~~~~~~~~~~~~~ ~~~
 help: consider using `if let` to clear intent
   |
 3 |     if let Some(_) = Some(42) {}
   |     ~~~~~~~~~~~~ ~~~

 warning: for loop over a `Result`. This is more readably written as an `if let` statement
  --> src/main.rs:4:14
   |
 4 |     for _ in Ok::<_, i32>(42) {}
   |              ^^^^^^^^^^^^^^^^
   |
 help: to check pattern in a loop use `while let`
   |
 4 |     while let Ok(_) = Ok::<_, i32>(42) {}
   |     ~~~~~~~~~~~~~ ~~~
 help: consider using `if let` to clear intent
   |
 4 |     if let Ok(_) = Ok::<_, i32>(42) {}
   |     ~~~~~~~~~~ ~~~

-warning: `for-loops-over-fallibles` (bin "for-loops-over-fallibles") generated 2 warnings
-    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.04s
+warning: for loop over a `&Option`. This is more readably written as an `if let` statement
+ --> src/main.rs:7:14
+  |
+7 |     for _ in &Some(42) {}
+  |              ^^^^^^^^^
+  |
+help: to check pattern in a loop use `while let`
+  |
+7 |     while let Some(_) = &Some(42) {}
+  |     ~~~~~~~~~~~~~~~ ~~~
+help: consider using `if let` to clear intent
+  |
+7 |     if let Some(_) = &Some(42) {}
+  |     ~~~~~~~~~~~~ ~~~
+
+warning: for loop over a `&mut Option`. This is more readably written as an `if let` statement
+ --> src/main.rs:8:14
+  |
+8 |     for _ in &mut Some(42) {}
+  |              ^^^^^^^^^^^^^
+  |
+help: to check pattern in a loop use `while let`
+  |
+8 |     while let Some(_) = &mut Some(42) {}
+  |     ~~~~~~~~~~~~~~~ ~~~
+help: consider using `if let` to clear intent
+  |
+8 |     if let Some(_) = &mut Some(42) {}
+  |     ~~~~~~~~~~~~ ~~~
+
+warning: for loop over a `&Result`. This is more readably written as an `if let` statement
+ --> src/main.rs:9:14
+  |
+9 |     for _ in &Ok::<_, i32>(42) {}
+  |              ^^^^^^^^^^^^^^^^^
+  |
+help: to check pattern in a loop use `while let`
+  |
+9 |     while let Ok(_) = &Ok::<_, i32>(42) {}
+  |     ~~~~~~~~~~~~~ ~~~
+help: consider using `if let` to clear intent
+  |
+9 |     if let Ok(_) = &Ok::<_, i32>(42) {}
+  |     ~~~~~~~~~~ ~~~
+
+warning: for loop over a `&mut Result`. This is more readably written as an `if let` statement
+  --> src/main.rs:10:14
+   |
+10 |     for _ in &mut Ok::<_, i32>(42) {}
+   |              ^^^^^^^^^^^^^^^^^^^^^
+   |
+help: to check pattern in a loop use `while let`
+   |
+10 |     while let Ok(_) = &mut Ok::<_, i32>(42) {}
+   |     ~~~~~~~~~~~~~ ~~~
+help: consider using `if let` to clear intent
+   |
+10 |     if let Ok(_) = &mut Ok::<_, i32>(42) {}
+   |     ~~~~~~~~~~ ~~~
+
+warning: `for-loops-over-fallibles` (bin "for-loops-over-fallibles") generated 6 warnings
+    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.02s

```

</details>

-----

Question:

* ~~Currently, the article `an` is used for `&Option`, and `&mut Option` in the lint diagnostic, since that's what `Option` uses. Is this okay or should it be changed? (likewise, `a` is used for `&Result` and `&mut Result`)~~ The article `a` is used for `&Option`, `&mut Option`, `&Result`, `&mut Result` and (as before) `Result`. Only `Option` uses `an` (as before).

`@rustbot` label +A-lint
2024-05-23 07:41:17 +02:00
León Orell Valerian Liehr
37bf2d2dab
Delay the construction of early lint diag structs
Fixes a slew of perf regressions.
2024-05-23 04:08:35 +02:00
León Orell Valerian Liehr
06bc4fc671
Remove LintDiagnostic::msg
* instead simply set the primary message inside the lint decorator functions
* it used to be this way before [#]101986 which introduced `msg` to prevent
  good path delayed bugs (which no longer exist) from firing under certain
  circumstances when lints were suppressed / silenced
* this is no longer necessary for various reasons I presume
* it shaves off complexity and makes further changes easier to implement
2024-05-23 04:08:35 +02:00
León Orell Valerian Liehr
ae49dbe707
Cleanup: Fix up some diagnostics 2024-05-22 22:40:34 +02:00
Urgau
1c7859e117 Don't suggest adding the unexpected cfgs the build-script it-self 2024-05-22 20:58:57 +02:00
Michael Goulet
8369dbba43 Use correct param-env in MissingCopyImplementations 2024-05-22 12:46:08 -04:00