Add test case for `missing_errors_doc` at tests with option `check-private-item=true`
Add test case for `missing_errors_doc` at tests with option `check-private-item=true` to proof that rust-lang/rust-clippy#13391 is not an issue anymore
changelog: none
Closes: rust-lang/rust-clippy#13391
Add units/unit prefixes of frequency to doc-valid-idents
These units/unit prefixes often come up in the embedded world.
Should this PR also modify the `test_units` test? It seems only concerned with data units currently; should it also test frequency units?
changelog: [`doc_markdown`]: Add MHz, GHz, and THz to `doc-valid-idents`.
Add debug assertions for empty replacements and overlapping spans
rustc has debug assertions [^1] [^2] that check that a substitution doesn't have an empty suggestion string and an empty span at the same time, as well as that spans in multipart suggestions don't overlap.
However, since we link to the rustc-dev distributed compiler, these debug assertions are always disabled and so we never actually run them.
This leads to the problem that the debug ICE is not necessarily caught in the PR and only triggered in the rust repo sync, and in one of the last syncs this was a blocker and delayed the sync by several weeks because the fix was not obvious.
So this PR essentially copies the checks over and runs them in clippy debug builds as well, so that we can catch these errors in PRs directly.
-----
As for the second commit, this also *did* cause an ICE in a sync before and was fixed in the sync PR (see https://github.com/rust-lang/rust/pull/120345#issuecomment-1911005554), but it seems like that commit didn't make it back into the clippy repo (cc `@flip1995),` so the fixed code is in the rust repo but not in the clippy repo.
changelog: none
[^1]: https://doc.rust-lang.org/1.82.0/nightly-rustc/src/rustc_errors/diagnostic.rs.html#1019
[^2]: https://doc.rust-lang.org/1.82.0/nightly-rustc/src/rustc_errors/diagnostic.rs.html#932
The expansion of `asm!()` and `line!()` is not marked as from an expansion, in which case `SourceMap::stmt_span` returns the input span unchanged. So instead of using `stmt_span`, use `mac_call_stmt_semi_span` directly
Allow to go through clippy lints page without javascript
Fixes#13536.
This is the follow-up of https://github.com/rust-lang/rust-clippy/pull/13269.
This PR makes it possible to expand/collapse lints (individually) without JS. To achieve this result, there are two ways:
1. Use `details` and `summary` tags. Problem with this approach is that the web browser search may open the `details` tags automatically if content matching it is inside. From a previous discussion with `@Alexendoo,` it seems to not be a desired behaviour.
2. Use a little trick where you use a `label` and a checkbox where the checkbox is in fact hidden. Then it's just a matter of CSS.
r? `@Alexendoo`
changelog: Allow to go through clippy lints page without JS
Use correct std/core prefix in lint output
changelog: none
I was waiting for #13452 to be merged before sending this one. `std` is used instead of `core` when appropriate in messages.
Fix lint `manual_slice_size_calculation` when a slice is ref more than once
When a slice is ref more than once, current suggestion given by `manual_slice_size_calculation` is wrong. For example:
```rs
let s: &[i32] = &[1, 2][..];
let ss: &&[i32] = &s; // <-----
let _ = size_of::<i32>() * ss.len();
```
clippy now suggests:
```patch
- let _ = size_of::<i32>() * ss.len();
+ let _ = size_of_val(ss);
```
However, this can result in calculating the size of `&[i32]`, instead of `[i32]` (this wrong suggestion also leads to `size_of_ref` warning: https://rust-lang.github.io/rust-clippy/master/index.html#/size_of_ref )
Now I am sending this PR to fix this bug, so that clippy will suggest (some deref added):
```patch
- let _ = size_of::<i32>() * ss.len();
+ let _ = size_of_val(*ss);
```
As I am not familiar with current clippy code-base, please correct me if I am not doing well or I can do it better :)
changelog: [`manual_slice_size_calculation`]: fix a bug when a slice is ref more than once.
[`implicit_saturating_sub`] Fix suggestion with a less volatile approach
Related to #13533, such and obvious mistake got pass my watch, quite embarassing :/
Revert #13533 and implement a more robust solution.
Revert "Fix span issue on `implicit_saturating_sub`
This reverts commit 140a1275f2.
changelog: [`lint_name`]: Fix suggestion for `if {} else if {} else {}` cases
r? `@y21`
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
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
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
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#117942Fixes#121161Fixes#121263Fixes#121299Fixes#121722Fixes#121799Fixes#126969Fixes#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
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
Don't warn on proc macro generated code in `needless_return`
Fixes#13458Fixes#13457Fixes#13467Fixes#13479Fixes#13481Fixes#13526Fixes#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
Don't warn on proc macro generated code in `needless_return`
Fixes#13458Fixes#13457Fixes#13467Fixes#13479Fixes#13481Fixes#13526Fixes#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
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
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
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`
