Disable ``[`new-without-default`]`` for new() methods that are marked…
… with '#[doc(hidden)]'
Fixes#8152
changelog: Disable ``[`new-without-default`]`` for new() methods that are marked with `#[doc(hidden)]`
rustc_errors: let `DiagnosticBuilder::emit` return a "guarantee of emission".
That is, `DiagnosticBuilder` is now generic over the return type of `.emit()`, so we'll now have:
* `DiagnosticBuilder<ErrorReported>` for error (incl. fatal/bug) diagnostics
* can only be created via a `const L: Level`-generic constructor, that limits allowed variants via a `where` clause, so not even `rustc_errors` can accidentally bypass this limitation
* asserts `diagnostic.is_error()` on emission, just in case the construction restriction was bypassed (e.g. by replacing the whole `Diagnostic` inside `DiagnosticBuilder`)
* `.emit()` returns `ErrorReported`, as a "proof" token that `.emit()` was called
(though note that this isn't a real guarantee until after completing the work on
#69426)
* `DiagnosticBuilder<()>` for everything else (warnings, notes, etc.)
* can also be obtained from other `DiagnosticBuilder`s by calling `.forget_guarantee()`
This PR is a companion to other ongoing work, namely:
* #69426
and it's ongoing implementation:
#93222
the API changes in this PR are needed to get statically-checked "only errors produce `ErrorReported` from `.emit()`", but doesn't itself provide any really strong guarantees without those other `ErrorReported` changes
* #93244
would make the choices of API changes (esp. naming) in this PR fit better overall
In order to be able to let `.emit()` return anything trustable, several changes had to be made:
* `Diagnostic`'s `level` field is now private to `rustc_errors`, to disallow arbitrary "downgrade"s from "some kind of error" to "warning" (or anything else that doesn't cause compilation to fail)
* it's still possible to replace the whole `Diagnostic` inside the `DiagnosticBuilder`, sadly, that's harder to fix, but it's unlikely enough that we can paper over it with asserts on `.emit()`
* `.cancel()` now consumes `DiagnosticBuilder`, preventing `.emit()` calls on a cancelled diagnostic
* it's also now done internally, through `DiagnosticBuilder`-private state, instead of having a `Level::Cancelled` variant that can be read (or worse, written) by the user
* this removes a hazard of calling `.cancel()` on an error then continuing to attach details to it, and even expect to be able to `.emit()` it
* warnings were switched to *only* `can_emit_warnings` on emission (instead of pre-cancelling early)
* `struct_dummy` was removed (as it relied on a pre-`Cancelled` `Diagnostic`)
* since `.emit()` doesn't consume the `DiagnosticBuilder` <sub>(I tried and gave up, it's much more work than this PR)</sub>,
we have to make `.emit()` idempotent wrt the guarantees it returns
* thankfully, `err.emit(); err.emit();` can return `ErrorReported` both times, as the second `.emit()` call has no side-effects *only* because the first one did do the appropriate emission
* `&mut Diagnostic` is now used in a lot of function signatures, which used to take `&mut DiagnosticBuilder` (in the interest of not having to make those functions generic)
* the APIs were already mostly identical, allowing for low-effort porting to this new setup
* only some of the suggestion methods needed some rework, to have the extra `DiagnosticBuilder` functionality on the `Diagnostic` methods themselves (that change is also present in #93259)
* `.emit()`/`.cancel()` aren't available, but IMO calling them from an "error decorator/annotator" function isn't a good practice, and can lead to strange behavior (from the caller's perspective)
* `.downgrade_to_delayed_bug()` was added, letting you convert any `.is_error()` diagnostic into a `delay_span_bug` one (which works because in both cases the guarantees available are the same)
This PR should ideally be reviewed commit-by-commit, since there is a lot of fallout in each.
r? `@estebank` cc `@Manishearth` `@nikomatsakis` `@mark-i-m`
better ObligationCause for normalization errors in `can_type_implement_copy`
Some logic is needed so we can point to the field when given totally nonsense types like `struct Foo(<u32 as Iterator>::Item);`
Fixes#93687
False positive redundant_closure when using ref pattern in closure params
fixes#8460
Fixed [redundant_closure] so that closures of which params bound as `ref` or `ref mut ` doesn't trigger the lint.
(e.g. `|ref x| some_expr` doesn't trigger the lint.)
changelog: none
tests: default to more threads for ui-tests
Benchmarks (tested on i5-7200U, 2 cores, 4 threads)
```
master branch:
cargo test // prime caches
cargo --color=always test 70,39s user 21,91s system 180% cpu 51,035 total
cargo --color=always test 70,77s user 22,13s system 180% cpu 51,579 total
cargo --color=always test 70,97s user 22,12s system 180% cpu 51,673 total
cargo --color=always nextest run 78,74s user 22,27s system 220% cpu 45,829 total
cargo --color=always nextest run 78,46s user 21,92s system 224% cpu 44,674 total
cargo --color=always nextest run 78,31s user 22,21s system 228% cpu 43,909 total
Patched (ui_speedup branch):
cargo test // prime cache
cargo --color=always test 97,51s user 32,02s system 288% cpu 44,905 total
cargo --color=always test 99,19s user 31,91s system 276% cpu 47,436 total
cargo --color=always test 98,47s user 31,84s system 284% cpu 45,744 total
cargo --color=always nextest run 102,18s user 30,80s system 350% cpu 37,902 total
cargo --color=always nextest run 99,75s user 29,86s system 350% cpu 36,935 total
cargo --color=always nextest run 100,36s user 29,93s system 351% cpu 37,061 total
```
changelog: use more threads for running clippys ui-tests for ~10% walltime speedup
Don't lint `match` expressions with `cfg`ed arms
Somehow there are no open issues related to this for any of the affected lints. At least none that I could fine from a quick search.
changelog: Don't lint `match` expressions with `cfg`ed arms in many cases
Benchmarks (tested on i5-7200U, 2 core 4 threads)
```
master branch:
cargo test // prime caches
cargo --color=always test 70,39s user 21,91s system 180% cpu 51,035 total
cargo --color=always test 70,77s user 22,13s system 180% cpu 51,579 total
cargo --color=always test 70,97s user 22,12s system 180% cpu 51,673 total
cargo --color=always nextest run 78,74s user 22,27s system 220% cpu 45,829 total
cargo --color=always nextest run 78,46s user 21,92s system 224% cpu 44,674 total
cargo --color=always nextest run 78,31s user 22,21s system 228% cpu 43,909 total
Patched (ui_speedup branch)
cargo test // prime cache
cargo --color=always test 97,51s user 32,02s system 288% cpu 44,905 total
cargo --color=always test 99,19s user 31,91s system 276% cpu 47,436 total
cargo --color=always test 98,47s user 31,84s system 284% cpu 45,744 total
cargo --color=always nextest run 102,18s user 30,80s system 350% cpu 37,902 total
cargo --color=always nextest run 99,75s user 29,86s system 350% cpu 36,935 total
cargo --color=always nextest run 100,36s user 29,93s system 351% cpu 37,061 total
```
Some more fixes for `transmute_undefined_repr`
changelog: Fix transmuting a struct containing a pointer into a pointer in `transmute_undefined_repr`
changelog: Allow various forms of type erasure in `transmute_undefined_repr`
Lint enum-to-int casts with `cast_possible_truncation`
fixes: #542
~~This will not lint casting a specific variant to an integer. That really should be a new lint as it's definitely a truncation (other than `isize`/`usize` values).~~
changelog: Lint enum-to-int casts with `cast_possible_truncation`
changelog: New lint `cast_enum_truncation`
Fix `await_holding_lock` not linting `parking_lot` Mutex/RwLock
This adds tests for `RwLock` and `parking_lot::{Mutex, RwLock}`, which were added before in 2dc8c083f5, but never tested in UI tests. I noticed this while reading [fasterthanli.me](https://fasterthanli.me/articles/a-rust-match-made-in-hell) latest blog post, complaining that Clippy doesn't catch this for `parking_lot`. (Too many people read his blog, he's too powerful)
Some more things:
- Adds a test for #6446
- Improves the lint message
changelog: [`await_holding_lock`]: Now also lints for `parking_lot::{Mutex, RwLock}`
Even though the FP for that the lints were moved to pedantic isn't fixed
yet, running the lintcheck tool over the most popular 279 crates didn't
trigger this lint once. I would say that this lint is valuable enough,
despite the known FP, to be warn-by-default. Especially since a pretty
nice workaround exists.
