Commit Graph

174 Commits

Author SHA1 Message Date
Ding Xiang Fei
b4b2b356d9
simplify the suggestion notes 2024-09-13 02:43:49 +08:00
Ding Xiang Fei
e2120a7c38
coalesce lint suggestions that can intersect 2024-09-11 04:10:03 +08:00
Ding Xiang Fei
f93df1f7dc
rescope temp lifetime in let-chain into IfElse
apply rules by span edition
2024-09-11 04:10:00 +08:00
Matthias Krüger
ccf3f6e59d
Rollup merge of #126452 - compiler-errors:raw-lifetimes, r=spastorino
Implement raw lifetimes and labels (`'r#ident`)

This PR does two things:
1. Reserve lifetime prefixes, e.g. `'prefix#lt` in edition 2021.
2. Implements raw lifetimes, e.g. `'r#async` in edition 2021.

This PR additionally extends the `keyword_idents_2024` lint to also check lifetimes.

cc `@traviscross`
r? parser
2024-09-07 23:30:10 +02:00
Michael Goulet
97910580aa Add initial support for raw lifetimes 2024-09-06 10:32:48 -04:00
Pavel Grigorenko
547db4a4b7 elided_named_lifetimes: manually implement LintDiagnostic 2024-09-06 15:47:52 +03:00
Pavel Grigorenko
dcfc71310d elided_named_lifetimes: add suggestions 2024-09-06 15:47:52 +03:00
Nadrieril
040239465a Add an internal lint that warns when accessing untracked data 2024-09-03 19:14:19 +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
Pavel Grigorenko
5d04472461 Implement elided_named_lifetimes lint 2024-08-31 15:35:41 +03: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
Ding Xiang Fei
ef25fbd0b4
lint on tail expr drop order change in Edition 2024 2024-08-21 01:05:21 +08:00
Urgau
c0c57b3e29 Disallow setting built-in cfgs via set the command-line 2024-08-07 14:08:34 +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
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
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
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
fdf8f024ad
Improve the impl and diag output of lint type_alias_bounds 2024-07-23 01:48:03 +02: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
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
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
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
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
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
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
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
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
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
许杰友 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
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
4f97ab54c4 Resolve elided lifetimes in assoc const to static if no other lifetimes are in scope 2024-06-14 11:05:35 -04: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
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
3ba8de0b60
Make extern blocks without unsafe warn in edition 2024 2024-06-04 14:19:42 -03:00
León Orell Valerian Liehr
b2949ff911
Spruce up the diagnostics of some early lints 2024-06-03 07:25:32 +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