Commit Graph

848 Commits

Author SHA1 Message Date
Guillaume Gomez
f9f3935fa7 Rollup merge of #143030 - Urgau:issue-143025, r=SparrowLii
Fix suggestion spans inside macros for the `unused_must_use` lint

This PR fixes the suggestion spans inside macros for the `unused_must_use` lint by trying to find the oldest ancestor span.

Fixes https://github.com/rust-lang/rust/issues/143025
2025-06-29 12:29:55 +02:00
Jonathan Brouwer
1249c14232 Port #[link_name] to the new attribute parsing infrastructure
Co-authored-by: Anne Stijns <anstijns@gmail.com>
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
2025-06-28 13:53:37 +02:00
Jonathan Brouwer
9e35684072 Port #[used] to new attribute parsing infrastructure
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
2025-06-27 08:58:26 +02:00
Jonathan Brouwer
287d9afce7 Port #[export_name] to the new attribute parsing infrastructure
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
2025-06-26 08:50:42 +02:00
Urgau
05d3d17248 Fix suggestion spans inside macros for the unused_must_use lint 2025-06-25 23:03:18 +02:00
Jubilee
2ad6272649 Rollup merge of #142825 - jdonszelmann:track-caller, r=oli-obk
Port `#[track_caller]` to the new attribute system

r? ``@oli-obk``

depends on https://github.com/rust-lang/rust/pull/142493

Closes rust-lang/rust#142783

(didn't add a test for this, this situation should simply never come up again, the code was simply wrong. lmk if I should add it, but it won't test something very useful)
2025-06-24 19:45:32 -07:00
Jana Dönszelmann
5d44fdd972 Rewrite #[track_caller] 2025-06-24 23:00:31 +02:00
Matthias Krüger
27819a009d Rollup merge of #142645 - Urgau:usage-non_upper_case_globals, r=fmease
Also emit suggestions for usages in the `non_upper_case_globals` lint

This PR adds suggestions for all the usages of the renamed item in the warning of the  `non_upper_case_globals` lint.

Fixes https://github.com/rust-lang/rust/issues/124061
2025-06-24 20:46:03 +02:00
Jonathan Brouwer
2084831cd5 Port #[no_mangle] to new attribute parsing infrastructure
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
2025-06-22 22:17:04 +02:00
Urgau
6ffd0e6c23 Address review comments 2025-06-22 16:45:16 +02:00
Jonathan Brouwer
b24df42488 Port #[must_use] to new attribute parsing infrastructure
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
2025-06-22 14:51:58 +02:00
Trevor Gross
c93fac7d64 Rollup merge of #142485 - mu001999-contrib:dead-code/adt-pattern, r=petrochenkov
Marks ADT live if it appears in pattern

Marks ADT live if it appears in pattern, it implies the construction of the ADT.
1. Then we can detect unused private ADTs impl `Default`, without special logics for `Default` and other std traits.
2. We can also remove `rustc_trivial_field_reads` on `Default`, and the logic in `should_ignore_item` (introduced by rust-lang/rust#126302).

Fixes rust-lang/rust#120770

Extracted from rust-lang/rust#128637.
r? `@petrochenkov`
2025-06-20 23:25:55 -04:00
Jana Dönszelmann
de0fd27f34 cold 2025-06-20 15:06:29 +02:00
Urgau
4df9f2f841 Emit the usages suggestions as tool-only suggestions 2025-06-18 19:15:10 +02:00
bors
1bb335244c Auto merge of #138165 - jdonszelmann:inline, r=oli-obk
Rewrite `inline` attribute parser to use new infrastructure and improve diagnostics for all parsed attributes

r? `@oli-obk`

This PR:
- creates a new parser for inline attributes
- creates consistent error messages and error codes between attribute parsers; inline and others
- as such changes a few error messages for other attributes to be (in my eyes) much more consistent
- tests ast-lowering lints introduced by rust-lang/rust#138164 since this is now useful for the first time
- Coalesce some useless error codes

Builds on top of rust-lang/rust#138164

Closes rust-lang/rust#137950
2025-06-18 06:25:21 +00:00
Urgau
42bb66add3 Also emit suggestions for usages in the non_upper_case_globals lint 2025-06-18 00:06:37 +02:00
Jana Dönszelmann
5ab5f8a24a make error codes reflect reality better 2025-06-17 23:22:51 +02:00
Jana Dönszelmann
ee976bbbca fix bugs in inline/force_inline and diagnostics of all attr parsers 2025-06-17 23:19:31 +02:00
xizheyin
72fbf3ea61 Dont suggest remove semi inside macro expansion for redundant semi lint
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
2025-06-18 00:36:51 +08:00
xizheyin
1ab8ff57d6 Add test suggest-remove-semi-in-macro-expansion-issue-142143.rs
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
2025-06-17 22:37:24 +08:00
bjorn3
3e944fa391 Remove all support for wasm's legacy ABI 2025-06-14 09:57:06 +00:00
Mu001999
52167e04e6 Marks ADT live if it appears in pattern 2025-06-14 13:44:43 +08:00
Matthias Krüger
8002683e99 Rollup merge of #128425 - tgross35:missing-fragment-specifier-unconditional, r=petrochenkov,traviscross
Make `missing_fragment_specifier` an unconditional error

This was attempted in [1] then reverted in [2] because of fallout. Recently, this was made an edition-dependent error in [3].

Make missing fragment specifiers an unconditional error again, across all editions.

More context: https://github.com/rust-lang/rust/pull/128006
Most recent crater: https://github.com/rust-lang/rust/pull/128425#issuecomment-2686949847
Fixes: https://github.com/rust-lang/rust/issues/40107

[1]: https://github.com/rust-lang/rust/pull/75516
[2]: https://github.com/rust-lang/rust/pull/80210
[3]: https://github.com/rust-lang/rust/pull/128006
2025-06-13 05:19:13 +02:00
Matthias Krüger
ae7615039f Rollup merge of #134536 - Urgau:fn-ptr-option, r=compiler-errors,traviscross
Lint on fn pointers comparisons in external macros

This PR extends the recently stabilized `unpredictable_function_pointer_comparisons` lint ~~to also lint on `Option<{function pointer}>` and~~ as well as linting in external macros (as to catch `assert_eq!` and others).

```rust
assert_eq!(Some::<FnPtr>(func), Some(func as unsafe extern "C" fn()));
//~^ WARN function pointer comparisons

#[derive(PartialEq, Eq)]
struct A {
    f: fn(),
    //~^ WARN function pointer comparisons
}
```

Fixes https://github.com/rust-lang/rust/issues/134527
2025-06-12 22:09:41 +02:00
Trevor Gross
841f7ce69a Make missing_fragment_specifier an unconditional error
This was attempted in [1] then reverted in [2] because of fallout.
Recently, this was made an edition-dependent error in [3].

Make missing fragment specifiers an unconditional error again.

[1]: https://github.com/rust-lang/rust/pull/75516
[2]: https://github.com/rust-lang/rust/pull/80210
[3]: https://github.com/rust-lang/rust/pull/128006
2025-06-12 07:57:12 +00:00
Urgau
fafc0f249f Report the unpredictable_function_pointer_comparisons lint in macro 2025-06-12 07:33:56 +02:00
Matthias Krüger
e2e201fd6b Rollup merge of #142219 - Kivooeo:tf11, r=wesleywiser
`tests/ui`: A New Order [11/N]

Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.

r? `@jieyouxu`
2025-06-12 03:14:52 +02:00
Kivooeo
c6c55cc0cb cleaned up some tests 2025-06-11 20:51:49 +05:00
Urgau
33beaba7c8 Always consider const _ items as live for dead code analysis 2025-06-09 15:48:06 +02:00
Guillaume Gomez
3c860e3764 Rollup merge of #142148 - workingjubilee:dont-ice-on-force-warn, r=Urgau
compiler: Treat ForceWarning as a Warning for diagnostic level

This silences an ICE.

No idea if this is the correct solution though tbh.

Fixes rust-lang/rust#142144
2025-06-07 22:22:59 +02:00
Guillaume Gomez
c475ad097f Rollup merge of #141661 - Urgau:deny-dangerous_implicit_autorefs, r=traviscross
Make the `dangerous_implicit_autorefs` lint deny-by-default

I intended for the `dangerous_implicit_autorefs` lint to be deny-by-default, the [T-lang nomination comment](https://github.com/rust-lang/rust/pull/123239#issuecomment-2727551097) even clearly mentioned deny-by-default, but somehow I and other missed that it is only warn-by-default.

I think the lint should still be deny-by-default as the implicit aliasing requirements can be quite dangerous.

In any-case, opening this PR for T-lang awareness.

`@rustbot` label +I-lang-nominated +T-lang
r? `@traviscross`
2025-06-07 22:22:57 +02:00
Guillaume Gomez
2c8a9cccd9 Rollup merge of #140560 - Urgau:test_attr-module-level, r=GuillaumeGomez
Allow `#![doc(test(attr(..)))]` everywhere

This PR adds the ability to specify [`#![doc(test(attr(..)))]`](https://doc.rust-lang.org/nightly/rustdoc/write-documentation/the-doc-attribute.html#testattr) ~~at module level~~ everywhere in addition to allowing it at crate-root.

This is motivated by a recent PR #140323 (by ````@tgross35)```` where we have to duplicate 2 attributes to every single `f16` and `f128` doctests, by allowing `#![doc(test(attr(..)))]` at module level (and everywhere else) we can omit them entirely and just have (in both module):

```rust
#![doc(test(attr(feature(cfg_target_has_reliable_f16_f128))))]
#![doc(test(attr(expect(internal_features))))]
```

Those new attributes are appended to the one found at crate-root or at a previous module. Those "global" attributes are compatible with merged doctests (they already were before).

Given the small addition that this is, I'm proposing to insta-stabilize it, but I can feature-gate it if preferred.

Best reviewed commit by commit.

r? ````@GuillaumeGomez````
2025-06-07 22:22:55 +02:00
Jubilee Young
5bab0d2e66 compiler: Treat ForceWarning as a Warning for diagnostic level
This silences an ICE.
2025-06-07 00:49:29 -07:00
bors
ccf3198de3 Auto merge of #138677 - shepmaster:consistent-elided-lifetime-syntax, r=traviscross,jieyouxu
Add a new `mismatched-lifetime-syntaxes` lint

The lang-team [discussed this](https://hackmd.io/nf4ZUYd7Rp6rq-1svJZSaQ) and I attempted to [summarize](https://github.com/rust-lang/rust/pull/120808#issuecomment-2701863833) their decision. The summary-of-the-summary is:

- Using two different kinds of syntax for elided lifetimes is confusing. In rare cases, it may even [lead to unsound code](https://github.com/rust-lang/rust/issues/48686)! Some examples:

    ```rust
    // Lint will warn about these
    fn(v: ContainsLifetime) -> ContainsLifetime<'_>;
    fn(&'static u8) -> &u8;
    ```

- Matching up references with no lifetime syntax, references with anonymous lifetime syntax, and paths with anonymous lifetime syntax is an exception to the simplest possible rule:

    ```rust
    // Lint will not warn about these
    fn(&u8) -> &'_ u8;
    fn(&'_ u8) -> &u8;
    fn(&u8) -> ContainsLifetime<'_>;
    ```

- Having a lint for consistent syntax of elided lifetimes will make the [future goal](https://github.com/rust-lang/rust/issues/91639) of warning-by-default for paths participating in elision much simpler.

---

This new lint attempts to accomplish the goal of enforcing consistent syntax. In the process, it supersedes and replaces the existing `elided-named-lifetimes` lint, which means it starts out life as warn-by-default.
2025-06-05 19:49:30 +00:00
bors
81a964c23e Auto merge of #142033 - matthiaskrgr:rollup-99lvg0j, r=matthiaskrgr
Rollup of 11 pull requests

Successful merges:

 - rust-lang/rust#141890 (Add link to correct documentation in htmldocck.py)
 - rust-lang/rust#141932 (Fix for async drop inside async gen fn)
 - rust-lang/rust#141960 (Use non-2015 edition paths in tests that do not test for their resolution)
 - rust-lang/rust#141968 (Run wfcheck in one big loop instead of per module)
 - rust-lang/rust#141969 (Triagebot: Remove `assign.users_on_vacation`)
 - rust-lang/rust#141985 (Ensure query keys are printed with reduced queries)
 - rust-lang/rust#141999 (Visit the ident in `PreciseCapturingNonLifetimeArg`.)
 - rust-lang/rust#142005 (Change `tag_field` to `FieldIdx` in `Variants::Multiple`)
 - rust-lang/rust#142017 (Fix incorrect use of "recommend" over "recommended")
 - rust-lang/rust#142024 (Don't refer to 'this tail expression' in expansion.)
 - rust-lang/rust#142025 (Don't refer to 'local binding' in extern macro.)

r? `@ghost`
`@rustbot` modify labels: rollup
2025-06-05 00:30:08 +00:00
Matthias Krüger
be2d382158 Rollup merge of #141960 - ferrocene:lw/2015-paths2, r=compiler-errors
Use non-2015 edition paths in tests that do not test for their resolution

This allows for testing these tests on editions other than 2015

Follow up to https://github.com/rust-lang/rust/pull/141888
2025-06-04 19:50:21 +02:00
Jake Goulding
d35ad94849 Replace elided_named_lifetimes with mismatched_lifetime_syntaxes 2025-06-04 10:40:04 -04:00
Matthias Krüger
820971581a Rollup merge of #141959 - ferrocene:lw/2015-edition-directives2, r=compiler-errors
Add more missing 2015 edition directives

These tests specifically test 2015 edition behavior, so ensure that they can only be run with this edition
2025-06-04 16:24:11 +02:00
Matthias Krüger
c5efc6aada Rollup merge of #137306 - tgross35:remove-i128-u128-improper-ctypes, r=traviscross,workingjubilee
Remove `i128` and `u128` from `improper_ctypes_definitions`

Rust's 128-bit integers have historically been incompatible with C [1]. However, there have been a number of changes in Rust and LLVM that mean this is no longer the case:

* Incorrect alignment of `i128` on x86 [1]: adjusting Rust's alignment proposed at https://github.com/rust-lang/compiler-team/issues/683, implemented at https://github.com/rust-lang/rust/pull/116672.
* LLVM version of the above: resolved in LLVM, including ABI fix. Present in LLVM18 (our minimum supported version).
* Incorrect alignment of `i128` on 64-bit PowerPC, SPARC, and MIPS [2]: Rust's data layouts adjusted at https://github.com/rust-lang/rust/pull/132422, https://github.com/rust-lang/rust/pull/132741, https://github.com/rust-lang/rust/pull/134115.
* LLVM version of the above: done in LLVM 20 https://github.com/llvm/llvm-project/issues/102783.
* Incorrect return convention of `i128` on Windows: adjusted to match GCC and Clang at https://github.com/rust-lang/rust/pull/134290.

At https://github.com/rust-lang/lang-team/issues/255#issuecomment-2088855084, the lang team considered it acceptable to remove `i128` from `improper_ctypes_definitions` if the LLVM version is known to be compatible. Time has elapsed since then and we have dropped support for LLVM versions that do not have the x86 fixes, meaning a per-llvm-version lint should no longer be necessary. The PowerPC, SPARC, and MIPS changes only came in LLVM 20 but since Rust's datalayouts have also been updated to match, we will be using the correct alignment regardless of LLVM version.

`repr(i128)` was added to this lint in https://github.com/rust-lang/rust/pull/138282, but is also removed here.

Part of the decision is that `i128` should match `__int128` in C on platforms that provide it, which documentation is updated to indicate. We will not guarantee that `i128` matches `_BitInt(128)` since that can be different from `__int128`. Some platforms (usually 32-bit) do not provide `__int128`; if any ABIs are extended in the future to define it, we will need to make sure that our ABI matches.

Closes: https://github.com/rust-lang/rust/issues/134288

[1]: https://github.com/rust-lang/rust/issues/54341
[2]: https://github.com/rust-lang/rust/issues/128950
2025-06-04 07:54:31 +02:00
Lukas Wirth
eae7fe1bdb Use non-2015 edition paths in tests that do not test for their resolution
This allows for testing these tests on editions other than 2015
2025-06-03 13:35:31 +02:00
Lukas Wirth
49969468b5 Add missing 2015 edition directives
These tests specifically test 2015 edition behavior, so ensure that they can only be run with this edition
2025-06-03 11:45:58 +02:00
Matthias Krüger
282c6654a0 Rollup merge of #141793 - Kivooeo:test-reform, r=jieyouxu
`tests/ui`: A New Order [1/N]

not sure if i should say something about changes here, just part of rust-lang/rust#133895

but this is my very first time doing something like this, id love to keep contributing in this area later on, so any feedback is appreciated

also should say that im going to squash it after agreement on changes

r? `@jieyouxu`

mind if i name this PR series like "`tests/ui`: A New Order [N/N]", im not sure if it fits the project tone, so id like your approval first — but i think it sounds really neat (Star Wars reference)

this could be a first part :)
2025-05-31 18:51:49 +02:00
Kivooeo
afc64242b6 cleaned up some tests 2025-05-31 19:49:19 +05:00
Matthias Krüger
896be667b8 Rollup merge of #141407 - mu001999-contrib:dead-code/refactor, r=petrochenkov
Refactor the two-phase check for impls and impl items

Refactor the two-phase dead code check to make the logic clearer and simpler:
1. adding assoc fn and impl into `unsolved_items` directly during the initial construction of the worklist
2. converge the logic of checking whether assoc fn and impl are used to `item_should_be_checked`, and the item is considered used only when its corresponding trait and Self adt are used

This PR only refactors as much as possible to avoid affecting the original functions. However, due to the adjustment of the order of checks, the test results are slightly different, but overall, there is no regression problem

Fixes rust-lang/rust#127911
Fixes rust-lang/rust#128839

Extracted from https://github.com/rust-lang/rust/pull/128637.
r? petrochenkov

try-job: dist-aarch64-linux
2025-05-30 07:01:29 +02:00
Matthias Krüger
7aba37da44 Rollup merge of #133823 - estebank:issue-56328, r=petrochenkov
Use `cfg_attr_trace` in AST with a placeholder attribute for accurate suggestion

In rust-lang/rust#138515, we insert a placeholder attribute so that checks for attributes can still know about the placement of `cfg` attributes. When we suggest removing items with `cfg_attr`s (fix rust-lang/rust#56328) and make them verbose. We tweak the wording of the existing "unused `extern crate`" lint.

```
warning: unused `extern crate`
  --> $DIR/removing-extern-crate.rs:9:1
   |
LL | extern crate removing_extern_crate as foo;
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ unused
   |
note: the lint level is defined here
  --> $DIR/removing-extern-crate.rs:6:9
   |
LL | #![warn(rust_2018_idioms)]
   |         ^^^^^^^^^^^^^^^^
   = note: `#[warn(unused_extern_crates)]` implied by `#[warn(rust_2018_idioms)]`
help: remove the unused `extern crate`
   |
LL - #[cfg_attr(test, macro_use)]
LL - extern crate removing_extern_crate as foo;
   |
```

r? `@petrochenkov`

try-job: x86_64-gnu-aux
2025-05-30 07:01:27 +02:00
Trevor Gross
0cba7fb6f6 Remove i128 and u128 from improper_ctypes_definitions
Rust's 128-bit integers have historically been incompatible with C [1].
However, there have been a number of changes in Rust and LLVM that
mean this is no longer the case:

* Incorrect alignment of `i128` on x86 [1]: adjusting Rust's alignment
  proposed at https://github.com/rust-lang/compiler-team/issues/683,
  implemented at https://github.com/rust-lang/rust/pull/116672.
* LLVM version of the above: resolved in LLVM, including ABI fix.
  Present in LLVM18 (our minimum supported version).
* Incorrect alignment of `i128` on 64-bit PowerPC, SPARC, and MIPS [2]:
  Rust's data layouts adjusted at
  https://github.com/rust-lang/rust/pull/132422,
  https://github.com/rust-lang/rust/pull/132741,
  https://github.com/rust-lang/rust/pull/134115.
* LLVM version of the above: done in LLVM 20
  https://github.com/llvm/llvm-project/issues/102783.
* Incorrect return convention of `i128` on Windows: adjusted to match
  GCC and Clang at https://github.com/rust-lang/rust/pull/134290.

At [3], the lang team considered it acceptable to remove `i128` from
`improper_ctypes_definitions` if the LLVM version is known to be
compatible. Time has elapsed since then and we have dropped support for
LLVM versions that do not have the x86 fixes, meaning a per-llvm-version
lint should no longer be necessary. The PowerPC, SPARC, and MIPS changes
only came in LLVM 20 but since Rust's datalayouts have also been updated
to match, we will be using the correct alignment regardless of LLVM
version.

`repr(i128)` was added to this lint in [4], but is also removed here.

Part of the decision is that `i128` should match `__int128` in C on
platforms that provide it, which documentation is updated to indicate.
We will not guarantee that `i128` matches `_BitInt(128)` since that can
be different from `__int128`. Some platforms (usually 32-bit) do not
provide `__int128`; if any ABIs are extended in the future to define it,
we will need to make sure that our ABI matches.

Closes: https://github.com/rust-lang/rust/issues/134288
Closes: https://github.com/rust-lang/rust/issues/128950

[1]: https://github.com/rust-lang/rust/issues/54341
[2]: https://github.com/rust-lang/rust/issues/128950
[3]: https://github.com/rust-lang/lang-team/issues/255#issuecomment-2088855084
[4]: https://github.com/rust-lang/rust/pull/138282
2025-05-29 12:55:26 +00:00
Mu001999
6eb6010368 Add test for issue 127911 and 128839 2025-05-29 20:51:51 +08:00
Esteban Küber
f80e3ac4ed Use cfg_attr AST placeholder AST cfg_attr_trace for diagnostics
PR 138515, we insert a placeholder attribute so that checks for attributes can still know about the placement of `cfg` attributes. When we suggest removing items with `cfg_attr`s (fix Issue 56328) and make them verbose. We tweak the wording of the existing "unused `extern crate`" lint.

```
warning: unused extern crate
  --> $DIR/removing-extern-crate.rs:9:1
   |
LL | extern crate removing_extern_crate as foo;
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ unused
   |
note: the lint level is defined here
  --> $DIR/removing-extern-crate.rs:6:9
   |
LL | #![warn(rust_2018_idioms)]
   |         ^^^^^^^^^^^^^^^^
   = note: `#[warn(unused_extern_crates)]` implied by `#[warn(rust_2018_idioms)]`
help: remove the unused `extern crate`
   |
LL - #[cfg_attr(test, macro_use)]
LL - extern crate removing_extern_crate as foo;
LL +
   |
```
2025-05-29 10:24:23 +00:00
beetrees
467eeabbb5 Stabilise repr128 2025-05-28 15:14:34 +01:00
Urgau
d851cfab33 Make the dangerous_implicit_autorefs lint deny-by-default 2025-05-27 21:14:48 +02:00