```
warning: unknown lint: `test_unstable_lint`
--> $DIR/warn-unknown-unstable-lint-inline.rs:4:10
|
LL | #![allow(test_unstable_lint, another_unstable_lint)]
| ^^^^^^^^^^^^^^^^^^
|
= note: the `test_unstable_lint` lint is unstable
= help: add `#![feature(test_unstable_lint)]` to the crate attributes to enable
= note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date
note: the lint level is defined here
--> $DIR/warn-unknown-unstable-lint-inline.rs:3:9
|
LL | #![warn(unknown_lints)]
| ^^^^^^^^^^^^^
warning: unknown lint: `test_unstable_lint`
--> $DIR/warn-unknown-unstable-lint-inline.rs:4:29
|
LL | #![allow(test_unstable_lint, another_unstable_lint)]
| ^^^^^^^^^^^^^^^^^^^^^
|
= note: the `test_unstable_lint` lint is unstable
= help: add `#![feature(test_unstable_lint)]` to the crate attributes to enable
= note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date
note: the lint level is defined here
--> $DIR/warn-unknown-unstable-lint-inline.rs:3:9
|
LL | #![warn(unknown_lints)]
| ^^^^^^^^^^^^^
```
This is particularly relevant when there are multiple lints in the same `warn` attribute. Pointing at the smaller span makes it clearer which one the warning is complaining about.
Use field init shorthand where possible
Field init shorthand allows writing initializers like `tcx: tcx` as
`tcx`. The compiler already uses it extensively. Fix the last few places
where it isn't yet used.
EDIT: this PR also updates `rustfmt.toml` to set
`use_field_init_shorthand = true`.
`compile::Assemble` is already complicated by its nature (as it handles core
internals like recursive building logic, etc.) and also handles half of `LldWrapper`
tool logic for no good reason since it should be done in the build step directly.
This change moves it there to reduce complexity of `compile::Assemble` logic.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Rollup of 11 pull requests
Successful merges:
- #130786 ( mir-opt: a sub-BB of a cleanup BB must also be a cleanup BB in `EarlyOtherwiseBranch`)
- #133926 (Fix const conditions for RPITITs)
- #134161 (Overhaul token cursors)
- #134253 (Overhaul keyword handling)
- #134394 (Clarify the match ergonomics 2024 migration lint's output)
- #134399 (Do not do if ! else, use unnegated cond and swap the branches instead)
- #134420 (refactor: replace &PathBuf with &Path to enhance generality)
- #134436 (tests/assembly/asm: Remove uses of rustc_attrs and lang_items features by using minicore)
- #134444 (Fix `x build --stage 1 std` when using cg_cranelift as the default backend)
- #134452 (fix(LazyCell): documentation of get[_mut] was wrong)
- #134460 (Merge some patterns together)
r? `@ghost`
`@rustbot` modify labels: rollup
Merge some patterns together
just something I noticed while browsing code. No change in functionality, deduplicates the 100% equal match arms by creating one big or pattern
fix(LazyCell): documentation of get[_mut] was wrong
- `LazyCell::get`: said it was returning a **mutable** reference.
- `LazyCell::get_mut`: said it was returning a reference (the mutable was missing).
Related to #129333 (`lazy_get`). `LazyLock`'s documentation was correct.
Fix `x build --stage 1 std` when using cg_cranelift as the default backend
Before, cg_cranelift would ICE when trying to lower f16 and f128. The library/ crates had all the infrastructure to omit using them, it just wasn't hooked up to bootstrap.
r? `````@bjorn3`````
tests/assembly/asm: Remove uses of rustc_attrs and lang_items features by using minicore
Similar to https://github.com/rust-lang/rust/pull/134385 (for tests/ui/asm), but for tests/assembly/asm.
r? jieyouxu
Do not do if ! else, use unnegated cond and swap the branches instead
I'm tidying up my ergonomic ref counting PR and I'm going to make some small, simple and unrelated changes outside that PR, so the main PR sticks more straight to the point.
Clarify the match ergonomics 2024 migration lint's output
This makes a few changes:
- Rather than using the whole pattern as a span for the lint, this collects spans for each problematic default binding mode reset and labels them with why they're problems.
- The lint's suggestions are now verbose-styled, so that it's clear what's being suggested vs. what's problematic.
- The wording is now less technical, and the hard error version of this diagnostic now links to the same reference material as the lint (currently an unwritten page of the edition guide).
I'm not totally confident in the wording or formatting, so I'd appreciate feedback on that in particular. I tried to draw a connection with word choice between the labels and the suggestion, but it might be imprecise, unclear, or cluttered. If so, it might be worth making the labels more terse and adding notes that explain them, but that's harder to read in a way too.
cc ```@Nadrieril``` ```@Jules-Bertholet```
Closes#133854. For reference, the error from that issue becomes:
```
error: pattern uses features incompatible with edition 2024
--> $DIR/remove-me.rs:6:25
|
LL | map.iter().filter(|(&(_x, _y), &_c)| false);
| ^ ^ cannot implicitly match against multiple layers of reference
| |
| cannot implicitly match against multiple layers of reference
|
help: make the implied reference pattern explicit
|
LL | map.iter().filter(|&(&(_x, _y), &_c)| false);
| +
```
Overhaul keyword handling
The compiler's list of keywords has some problems.
- It contains several items that aren't keywords.
- The order isn't quite right in a couple of places.
- Some of the names of predicates relating to keywords are confusing.
- rustdoc and rustfmt have their own (incorrect) versions of the keyword list.
- `AllKeywords` is unnecessarily complex.
r? ```@jieyouxu```
Move the dist-aarch64-linux CI job to an aarch64 runner instead of
cross-compiling it from an x86 one. This will make it possible to
perform optimisations such as LTO, PGO and BOLT later on.
`gen` is an edition-specific keyword used in unstable Rust, and so
belongs with `try` (as `is_unused_keyword_conditional` indicates).
Also, the cases in `is_unused_keyword_conditional` should be in
alphabetical order, to match the keyword list.
These changes don't affect the behaviour of any of the `Symbol::is_*`
functions.
