Commit Graph

20952 Commits

Author SHA1 Message Date
blyxyas
2b562dece6 Fix suggestion with a less volatile approach
Revert "Fix span issue on `implicit_saturating_sub`"
This reverts commit 140a1275f2.
2024-10-12 17:43:06 +02:00
xFrednet
8b075fc634
Move clippy::module_name_repetitions to restriction (from pedantic)
Rational:
- Too pedantic IMO, it's often better to have fine grained modules and
  then rexport stuff instead of one gigantic file
- STD doesn't do this either. Examples:
  - std::vec::Vec
  - std::collections::vec_deque::VecDequeue
- rust-clippy#7666 commonly ignored
2024-10-12 12:03:24 +02:00
bors
48e98ec68d Auto merge of #13537 - Manishearth:applicable, r=xFrednet
Mark unnecessary_first_then_check and byte_char_slices as Applicable

I don't really see situations where this isn't Applicable that aren't weird edge cases where the lint should be disabled.

changelog: none
2024-10-11 22:25:00 +00:00
Manish Goregaokar
42723dc9df Mark unnecessary_first_then_check and byte_char_slices as Applicable 2024-10-11 12:20:07 -07:00
bors
b85f632607 Auto merge of #13528 - zvavybir:master, r=Alexendoo
Improved wording of or_fun_call lint

The current wording (e.g. ``use of `ok_or` followed by a function call``) is potentially confusing (at least it confused me) by suggesting that the function that follows the (in this case) `ok_or` is the problem and not the function that is an argument to it.

The code in my program that triggered the confusing message is the following:
```rust
let file_id = buf
    .lines()
    .next()
    .ok_or((
        InternalError::ProblemReadingFromInbox,
        anyhow!("No first line in inbox response ({file:?}): {buf:?}"),
    ))
    .html_context(stream, lang)?;
```
I thought that `html_context` was the problem and that I should do something along the following lines:
```rust
let file_id = buf
    .lines()
    .next()
    .ok_or_else(
        (
            InternalError::ProblemReadingFromInbox,
            anyhow!("No first line in inbox response ({file:?}): {buf:?}"),
        ),
        html_context(stream, lang),
    )?
```
This is of course wrong.  My confusion was only cleared up through the help message indicating what I should try instead.

If someone has a better idea of a replacement wording (currently e.g. ``` function call inside of `ok_or` ```), I'm all ears.

changelog: none
2024-10-11 15:01:07 +00:00
bors
6f1def79dd Auto merge of #13269 - GuillaumeGomez:rewrite-lints-page, r=Alexendoo
Rewrite lints page

This PR has multiple goals:

* Make lints page to work without needing a web server by removing the json file.
* Prepare the field to also make the page work with JS (not done in this PR but should be straightforward).
* Remove angular dependency.

r? `@Alexendoo`

changelog: make lint page work without web server
2024-10-11 14:18:54 +00:00
bors
8125cd5c2a Auto merge of #13359 - blyxyas:declare_clippy_macro, r=Alexendoo
Turn declare_clippy_lint into a declarative macro

Ease of development, and hopefully compile times (the dependencies are still there because of ui-test). The procedural macro was doing just some very basic processing (like assigning a lint level to each category), so it didn't have a reason to stay IMO

changelog: None
2024-10-11 14:10:01 +00:00
bors
f5cc292830 Auto merge of #131045 - compiler-errors:remove-unnamed_fields, r=wesleywiser
Retire the `unnamed_fields` feature for now

`#![feature(unnamed_fields)]` was implemented in part in #115131 and #115367, however work on that feature has (afaict) stalled and in the mean time there have been some concerns raised (e.g.[^1][^2]) about whether `unnamed_fields` is worthwhile to have in the language, especially in its current desugaring. Because it represents a compiler implementation burden including a new kind of anonymous ADT and additional complication to field selection, and is quite prone to bugs today, I'm choosing to remove the feature.

However, since I'm not one to really write a bunch of words, I'm specifically *not* going to de-RFC this feature. This PR essentially *rolls back* the state of this feature to "RFC accepted but not yet implemented"; however if anyone wants to formally unapprove the RFC from the t-lang side, then please be my guest. I'm just not totally willing to summarize the various language-facing reasons for why this feature is or is not worthwhile, since I'm coming from the compiler side mostly.

Fixes #117942
Fixes #121161
Fixes #121263
Fixes #121299
Fixes #121722
Fixes #121799
Fixes #126969
Fixes #131041

Tracking:
* https://github.com/rust-lang/rust/issues/49804

[^1]: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Unnamed.20struct.2Funion.20fields
[^2]: https://github.com/rust-lang/rust/issues/49804#issuecomment-1972619108
2024-10-11 13:11:13 +00:00
bors
47903dbf97 Auto merge of #13532 - y21:issue13531, r=Alexendoo
Only emit `manual_c_str_literals` in >= Edition 2021

Fixes #13531

changelog: none
2024-10-11 12:47:38 +00:00
bors
05f3793392 Auto merge of #13534 - GnomedDev:fix-large-stack-arrays-nested-item, r=flip1995
Fix large_stack_arrays triggering when nesting const items

Fixes #13529.

r? `@flip1995`

changelog: [`large_stack_arrays`]: No longer triggers in static/const context when using nested items
2024-10-11 09:04:46 +00:00
bors
14c05c974c Auto merge of #13533 - blyxyas:fix-implicit_saturating_sub, r=dswij
Fix span issue on `implicit_saturating_sub`

Fixes #13524

changelog: [`implicit_saturating_sub`]: Fix span issue on else blocks
2024-10-11 06:25:08 +00:00
GnomedDev
87b4c1ffb7
Fix large_stack_arrays triggering when nesting const items 2024-10-10 22:01:46 +01:00
blyxyas
140a1275f2 Fix span issue on implicit_saturating_sub
Fixes #13524
2024-10-10 19:10:04 +02:00
Alexey Semenyuk
cb19f23c79 Clean up const_float_classify leftovers 2024-10-10 22:08:45 +05:00
y21
2b86ffc57e only emit manual_c_str_literals in >= edition2021 2024-10-10 18:08:40 +02:00
bors
5840f78c6c Auto merge of #13530 - blyxyas:back-from-burnout, r=blyxyas
Back from burnout

This reverts commit 5ea7044d72. I needed some time free from reviewing to focus on the Project Goal and myself.

Now I'm much better, and we can continue reviewing!

I hope that I can approve this myself 😅

changelog: none
2024-10-10 12:42:58 +00:00
blyxyas
2acc0c37da Revert "Temporarily remove myself from reviewer rotation"
This reverts commit 5ea7044d72.
I'm back from burnout, we're ready again!
2024-10-10 14:12:35 +02:00
bors
806a9dfddd Auto merge of #13464 - y21:issue13458, r=flip1995
Don't warn on proc macro generated code in `needless_return`

Fixes #13458
Fixes #13457
Fixes #13467
Fixes #13479
Fixes #13481
Fixes #13526
Fixes #13486

The fix is unfortunately a little more convoluted than just simply adding a `is_from_proc_macro`. That check *does*  fix the issue, however it also introduces a bunch of false negatives in the tests, specifically when the returned expression is in a different syntax context, e.g. `return format!(..)`.

The proc macro check builds up a start and end pattern based on the HIR nodes and compares it to a snippet of the span, however that would currently fail for `return format!(..)` because we would have the patterns `("return", <something inside of the format macro>)`, which doesn't compare equal. So we now return an empty string pattern for when it's in a different syntax context.

"Hide whitespace" helps a bit for reviewing the proc macro detection change

changelog: none
2024-10-10 11:34:13 +02:00
bors
8e60f143d8 Auto merge of #13464 - y21:issue13458, r=flip1995
Don't warn on proc macro generated code in `needless_return`

Fixes #13458
Fixes #13457
Fixes #13467
Fixes #13479
Fixes #13481
Fixes #13526
Fixes #13486

The fix is unfortunately a little more convoluted than just simply adding a `is_from_proc_macro`. That check *does*  fix the issue, however it also introduces a bunch of false negatives in the tests, specifically when the returned expression is in a different syntax context, e.g. `return format!(..)`.

The proc macro check builds up a start and end pattern based on the HIR nodes and compares it to a snippet of the span, however that would currently fail for `return format!(..)` because we would have the patterns `("return", <something inside of the format macro>)`, which doesn't compare equal. So we now return an empty string pattern for when it's in a different syntax context.

"Hide whitespace" helps a bit for reviewing the proc macro detection change

changelog: none
2024-10-10 09:17:20 +00:00
Matthias Kaak
8c46c498d9 Improved wording of or_fun_call lint
Signed-off-by: Matthias Kaak <zvavybir@zvavybir.eu>
2024-10-10 08:05:41 +00:00
xFrednet
731c473fd9
Changelog for Clippy 1.82 ✈️ 2024-10-09 19:04:21 +02:00
xFrednet
33018b46f4
Update version attribute for 1.81 lints 2024-10-09 19:04:20 +02:00
bors
1f8f982f22 Auto merge of #13504 - samueltardieu:needless-raw-strings, r=Alexendoo
Check for needless raw strings in `format_args!()` template as well

changelog: [`needless_raw_strings`, `needless_raw_string_hashes`]: check `format_args!()` template as well

Fix #13503
2024-10-09 01:35:08 +00:00
bors
d9c8d976cb Auto merge of #13512 - samueltardieu:issue-13511, r=xFrednet
`infinite_loop`: continuing an outer loop leaves the inner loop

changelog: [`infinite_loop`]: detect a `continue` targeting an outer loop

Fix #13511
2024-10-08 08:49:07 +00:00
Eric Holk
c038c3030b Add sugar for &pin (const|mut) types 2024-10-07 11:15:04 -07:00
bors
6f4bf9057a Auto merge of #13329 - RalfJung:git-commit-rerun, r=Alexendoo,flip1995
rustc_tools_util: rerun when git commit changes

Fixes https://github.com/rust-lang/rust-clippy/issues/13312

changelog: none
2024-10-07 17:36:04 +00:00
Philipp Krones
fba7ea7e97
Bump rust-tools-util version in Clippy Cargo.toml 2024-10-07 19:32:18 +02:00
Philipp Krones
65fdfb835c
Update README and CHANGELOG 2024-10-07 19:23:50 +02:00
Ralf Jung
eb6c346137
rustc_tools_util: bump version 2024-10-07 19:23:50 +02:00
Ralf Jung
9f7a09021d
rustc_tools_util: rerun when git commit changes 2024-10-07 19:23:50 +02:00
Samuel Tardieu
36c31db705 Apply updated needless_raw_strings to Clippy sources 2024-10-07 18:29:25 +02:00
Samuel Tardieu
5e78c15caa raw_strings: handle format template as well 2024-10-07 18:29:24 +02:00
bors
b013e69692 Auto merge of #13496 - y21:issue10619, r=Alexendoo
Show interior mutability chain in `mutable_key_type`

Fixes #10619

Just ran into this myself and I definitely agree it's not very nice to have to manually go through all the types involved to figure out why this happens and to evaluate if this is really a problem (knowing if the field of a struct is something that a hash impl relies on), so this changes the lint to emit notes for each step involved.

changelog: none
2024-10-07 15:32:34 +00:00
bors
65d941d644 Auto merge of #131354 - matthiaskrgr:rollup-hprnng2, r=matthiaskrgr
Rollup of 4 pull requests

Successful merges:

 - #131331 (Revert "warn_old_master_branch" check)
 - #131344 (Avoid `&Lrc<T>` in various places)
 - #131346 (Restrict `ignore-mode-*` directives)
 - #131353 (Add documentation for `runtest::check_rustdoc_test_option` method)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-07 11:30:33 +00:00
Nicholas Nethercote
121d3ab89e Avoid another &Lrc<..> in a return value. 2024-10-07 13:59:50 +11:00
Samuel Tardieu
99ce411ed6 infinite_loop: continuing an outer loop leaves the inner loop 2024-10-06 19:19:27 +02:00
bors
1c9e5d0e5c Auto merge of #13513 - samueltardieu:push-zvvzytrovulq, r=y21
Style: do not defensively use `saturating_sub()`

Using `saturating_sub()` here in code which cannot fail brings a false sense of security. If for any reason a logic error was introduced and caused `self.loop_depth` to reach 0 before being decremented, using `saturating_sub(1)` would silently mask the programming error instead of panicking loudly as it should (at least in dev profile).

changelog: none
2024-10-06 17:15:53 +00:00
Samuel Tardieu
af6816c5b6 infinite_loop: do not defensively use saturating_sub()
Using `saturating_sub()` here in code which cannot fail brings a false
sense of security. If for any reason a logic error was introduced and
caused `self.loop_depth` to reach 0 before being decremented, using
`saturating_sub(1)` would silently mask the programming error instead of
panicking loudly as it should (at least in dev profile).
2024-10-06 18:52:24 +02:00
codemountains
2226f16945 Rename NestedMetaItem to MetaItemInner 2024-10-06 23:28:30 +09:00
bors
f7aaecf3f5 Auto merge of #13506 - samueltardieu:push-zyqvkwlswvkk, r=xFrednet
unused_result_ok: added in Clippy 1.82.0, not 1.70.0

changelog: none

Fix #13497
2024-10-06 11:33:31 +00:00
bors
2d2e8cc21f Auto merge of #13485 - GnomedDev:reduce-large-threshold, r=xFrednet
Reduce default 'large array' threshold

As-is this threshold is `512kb`, but as #9449 points out this is way too high for most people to consider sensible (why would you want to copy `256kb` of data around on the stack or duplicate it via `const`) and didn't get any discussion when originally added. This PR reduces it the threshold to `1kb`, which is higher than the issue says ("a few cpu words") but helps out for actual codebases.

While reducing this, I found that `large_stack_arrays` was triggering for statically promoted arrays in constants/statics, so I also fixed that up as seen in the difference to [array_size_threshold.stderr](https://github.com/rust-lang/rust-clippy/compare/master...GnomedDev:rust-clippy:reduce-large-threshold?expand=1#diff-4c2a2a855d9ff7777f1d385be0c1bede2a3fc8aaab94837cde27a35235233fc7).

Closes #9449.

changelog: [`large_stack_arrays`]: No longer triggers in `static`/`const` context
changelog: [`large_const_arrays`]: Changed the default of [`array-size-threshold`] from `512kb` to `16kb`
2024-10-06 11:24:28 +00:00
bors
d0507302fc Auto merge of #130540 - veera-sivarajan:fix-87525, r=estebank
Add a Lint for Pointer to Integer Transmutes in Consts

Fixes #87525

This PR adds a MirLint for pointer to integer transmutes in const functions and associated consts. The implementation closely follows this comment: https://github.com/rust-lang/rust/pull/85769#issuecomment-880969112. More details about the implementation can be found in the comments.

Note: This could break some sound code as mentioned by RalfJung in https://github.com/rust-lang/rust/pull/85769#issuecomment-886491680:

> ... technically const-code could transmute/cast an int to a ptr and then transmute it back and that would be correct -- so the lint will deny some sound code. Does not seem terribly likely though.

References:
1. https://doc.rust-lang.org/std/mem/fn.transmute.html
2. https://doc.rust-lang.org/reference/items/associated-items.html#associated-constants
2024-10-06 02:39:23 +00:00
Samuel Tardieu
0596a04bf4 unused_result_ok: added in Clippy 1.82.0, not 1.70.0 2024-10-05 23:50:14 +02:00
Samuel Tardieu
846bd30cfe raw_strings: separate raw string detection from lint logic 2024-10-05 23:17:29 +02:00
bors
753629bb33 Auto merge of #13412 - GnomedDev:regex-comp-in-loop, r=y21
Implement lint for regex::Regex compilation inside a loop

Closes #598.

Seems like a pretty simple one, I'm not sure if I sorted out all the lint plumbing correctly because I was adding it to the existing regex pass, but seems to work. The name is a bit jank and I'm super open to suggestions for changing it.

changelog: [`regex_creation_in_loops`]: Added lint for Regex compilation inside loops.
2024-10-05 18:41:45 +00:00
bors
f173eb3aef Auto merge of #13505 - samueltardieu:lintcheck-bump-futures, r=y21
lintcheck: bump futures* crates to 0.3.31

changelog: none
2024-10-05 18:21:17 +00:00
Samuel Tardieu
9dd6820edd lintcheck: bump futures* crates to 0.3.31
Version 0.3.30 doesn't compile with our nightly version.
2024-10-05 19:04:45 +02:00
GnomedDev
196dbcf6d5
Avoid linting for Regexes compiled in items defined in loops 2024-10-05 17:10:21 +01:00
Veera
98b59a1cf6 Add a Lint for Pointer to Integer Transmutes in Consts 2024-10-05 12:48:02 +00:00
Matthias Krüger
a0653c5e98 Rollup merge of #131256 - RalfJung:f16-f128-const, r=ibraheemdev
move f16/f128 const fn under f16/f128 feature gate

The `*_const` features were added to work around https://github.com/rust-lang/rust/issues/129656, which should not be needed any more.
2024-10-05 13:15:58 +02:00