Of the error levels satisfying `is_error`, `Level::Error` is the only
one that can be a lint, so there's no need to check for it.
(And even if it wasn't, it would make more sense to include
non-`Error`-but-`is_error` lints under `lint_err_count` than under
`err_count`.)
There are four functions that adjust error and warning counts:
- `stash_diagnostic` (increment)
- `steal_diagnostic` (decrement)
- `emit_stashed_diagnostics) (decrement)
- `emit_diagnostic` (increment)
The first three all behave similarly, and only update `warn_count` for
forced warnings. But the last one updates `warn_count` for both forced
and non-forced warnings.
Seems like a bug. How should it be fixed? Well, `warn_count` is only
used in one place: `DiagCtxtInner::drop`, where it's part of the
condition relating to the printing of `good_path_delayed_bugs`. The
intention of that condition seems to be "have any errors been printed?"
so this commit replaces `warn_count` with `has_printed`, which is set
when printing occurs. This is simpler than all the ahead-of-time
incrementing and decrementing.
`is_force_warn` is only possible for diagnostics with `Level::Warning`,
but it is currently stored in `Diagnostic::code`, which every diagnostic
has.
This commit:
- removes the boolean `DiagnosticId::Lint::is_force_warn` field;
- adds a `ForceWarning` variant to `Level`.
Benefits:
- The common `Level::Warning` case now has no arguments, replacing
lots of `Warning(None)` occurrences.
- `rustc_session::lint::Level` and `rustc_errors::Level` are more
similar, both having `ForceWarning` and `Warning`.
When writing a no_std binary, you'll be greeted with nonsensical errors
mentioning lang items like eh_personality and start. That's pretty bad
because it makes you think that you need to define them somewhere! But
oh no, now you're getting the `internal_features` lint telling you that
you shouldn't use them! But you need a no_std binary! What now?
No problem! Writing a no_std binary is super easy. Just use panic=abort
and supply your own platform specific entrypoint symbol (like `main`)
and you're good to go. Would be nice if the compiler told you that,
right?
This makes it so that it does do that.
Diagnostic API fixes
Some improvements to diagnostic APIs: improve some naming, use shortcuts in more places, and add a couple of missing methods.
r? `@compiler-errors`
rust-analyzer has logic that discounts suggesting `use`s for private
imports, but that logic is unnecessarily strict - for instance given
this code:
```rust
mod foo {
pub struct Foo;
}
pub(crate) use self::foo::*;
mod bar {
fn main() {
Foo$0;
}
}
```
... RA will suggest to add `use crate::foo::Foo;`, which not only makes
the code overly verbose (especially in larger code bases), but also is
disjoint with what rustc itself suggests.
This commit adjusts the logic, so that `pub(crate)` imports are taken
into account when generating the suggestions; considering rustc's
behavior, I think this change doesn't warrant any extra configuration
flag.
Note that this is my first commit to RA, so I guess the approach taken
here might be suboptimal - certainly feels somewhat hacky, maybe there's
some better way of finding out the optimal import path 😅
This option is largely there to help people to manage the memory usage
on their systems during the LLVM build. The linking phase is as usual
are the heaviest part of the build and if in an unlucky conincidence the
circumstances align to kick off N_CORES links at the same time, not even
hundreds of GiB of memory may suffice. It makes a lot of sense for
developers to set&forget this option unconditionally.
Not to mention, this option does not, in any way, affect the generated
code (at least as far as I know.) It really doesn’t matter what
option the CI build LLVM used here and/or if it matches with the user’s
configuration.
Finally, 0 actual link jobs implied by `download-ci-llvm` is guaranteed
to stay within the limits that are reasonable to set with this option.
Replace SourceRootCrates hashset output with slice for deterministic order
We only iterate over the result, and its pretty small in general so no point for the `HashSet` (additionally this way we get a more defined iteration order).
minor: Mark unresolved associated item diagnostic as experimental
Per #16327 unresolved associated item has false positives. Mark the diagnostic as experimental until this is more dependable.
Preserve comments for extracted block expression in 'extract_function'
Fix#14371
Preserve comments for extracted block expression in 'extract_function'.
In the original implementation, `block.statements()` was used to construct a new function, removing the comments within the block. In the updated implementation, we use manual traversal of nodes and `hacky_block_expr` to generate a new block, thereby preserving the comments.
Rollup of 4 pull requests
Successful merges:
- #106893 (Explain base expression for struct update syntax)
- #119769 (rustdoc: offset generic args of cross-crate trait object types when cleaning)
- #119772 (Fix an ICE that occurs after an error has already been reported)
- #119782 (rint intrinsics: caution against actually trying to check for floating-point exceptions)
r? `@ghost`
`@rustbot` modify labels: rollup
rustdoc: offset generic args of cross-crate trait object types when cleaning
Fixes#119529.
This PR contains several refactorings apart from the bug fix.
Best reviewed commit by commit.
r? GuillaumeGomez
Update cargo
14 commits in 2ce45605d9db521b5fd6c1211ce8de6055fdb24e..3e428a38a34e820a461d2cc082e726d3bda71bcb
2024-01-04 18:04:13 +0000 to 2024-01-09 20:46:36 +0000
- refactor: replace `iter_join` with `itertools::join` (rust-lang/cargo#13275)
- docs(unstable): doc comments for items and fields (rust-lang/cargo#13274)
- crates-io: Set `Content-Type: application/json` only for requests with a body payload (rust-lang/cargo#13264)
- fix: only inherit workspace package table if the new package is a member (rust-lang/cargo#13261)
- feat(cli): add colors to `-Zhelp` console output (rust-lang/cargo#13269)
- chore(deps): update msrv (rust-lang/cargo#13266)
- refactor(toml): Make it more obvious to update package-dependent fields (rust-lang/cargo#13267)
- chore(ci): Fix MSRV:3 updates (rust-lang/cargo#13268)
- chore(ci): Shot-in-the-dark fix for MSRV updating (rust-lang/cargo#13265)
- fix: set OUT_DIR for all units with build scripts (rust-lang/cargo#13204)
- fix(manifest): Provide unused key warnings for lints table (rust-lang/cargo#13262)
- test(manifest): Verify we warn on unused workspace.package fields (rust-lang/cargo#13263)
- docs(changelog): Call out cargo-new lockfile change (rust-lang/cargo#13260)
- chore: Add dependency dashboard (rust-lang/cargo#13255)
r? ghost
Extend `useless_asref` lint on `map(clone)`
If you have code like:
```rust
Some(String::new()).as_ref().map(Clone::clone)
```
the `as_ref` call is unneeded.
Interestingly enough, this lint and `map_clone` are starting to share a same "space" where both lints warn about different things for the same code. Not sure what's the policy about such cases though...
r? `@llogiq`
changelog: Extend `useless_asref` lint on `map(clone)`
This removes emit_enum_variant and the emit_usize calls that resulted
in. In libcore this eliminates 17% of leb128, taking us from 8964488 to
7383842 leb128's serialized.
100% of the serialized enums during libcore compilation fit into the
smaller tag, and this eliminates hitting the leb128 code for
coding/decoding when we can statically guarantee that's not required.
30% of all leb128 integers serialized in libcore (12981183 total) come
from the usize's removed here.
