Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#142502 (rustdoc_json: improve handling of generic args)
- rust-lang/rust#142597 (error on calls to ABIs that cannot be called)
- rust-lang/rust#142785 (fix(linkcheck): Build using the lockfile)
- rust-lang/rust#142787 (Add diagnostic items for Clippy)
- rust-lang/rust#142788 (add doc(alias("AsciiChar")) to core::ascii::Char)
- rust-lang/rust#142801 (Use gen blocks in the compiler instead of `from_coroutine`)
- rust-lang/rust#142804 (Rename `LayoutS` to `LayoutData` in comments)
r? `@ghost`
`@rustbot` modify labels: rollup
Rename `LayoutS` to `LayoutData` in comments
`LayoutS` was renamed to `LayoutData`, but some comments in the compiler were not changed. This updates comments in the compiler (and one section of commented-out code in rust-analyzer) to refer to `LayoutData` instead of `LayoutS`.
cc <https://github.com/rust-lang/rust/pull/132252>, `@workingjubilee`
add doc(alias("AsciiChar")) to core::ascii::Char
Added it to the reexported, which is intended rustdoc behavior, but is apparently untested, so I also added a test for it.
Add diagnostic items for Clippy
Clippy still uses some paths to access items from the standard library. Adding the missing diagnostic items allows removing the last remaining paths.
Closesrust-lang/rust-clippy#5393
Add diagnostic items for Clippy
Clippy still uses some paths to access items from the standard library. Adding the missing diagnostic items allows removing the last remaining paths.
Closesrust-lang/rust-clippy#5393
error on calls to ABIs that cannot be called
We recently added `extern "custom"`, which cannot be called using a rust call expression. But there are more ABIs that can't be called in that way, because the call does not semantically make sense.
More details are in https://github.com/rust-lang/rust/issues/140566#issuecomment-2846205457
r? `@workingjubilee`
try-job: x86_64-gnu-llvm-19-3
rustdoc_json: improve handling of generic args
This PR fixes some inconsistencies and inefficiencies in how generic args are handled by rustdoc-json-types.
r? `@aDotInTheVoid`
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#142384 (Bringing `rustc_rayon_core` in tree as `rustc_thread_pool`)
- rust-lang/rust#142476 (Insert parentheses around binary operation with attribute)
- rust-lang/rust#142485 (Marks ADT live if it appears in pattern)
- rust-lang/rust#142571 (Reason about borrowed classes in CopyProp.)
- rust-lang/rust#142677 (Add CI check to ensure that rustdoc JSON `FORMAT_VERSION` is correctly updated)
- rust-lang/rust#142716 (Adjust `with_generic_param_rib`.)
- rust-lang/rust#142756 (Make `Clone` a `const_trait`)
- rust-lang/rust#142765 (rustc_target: document public AbiMap-related fn and variants)
r? `@ghost`
`@rustbot` modify labels: rollup
They show up in three places: once as `Option<Box<GenericArgs>>`, once
as `Box<GenericArgs>`, and once as `GenericArgs`. The first option is
best. It is more compact because generic args are often missing. This
commit changes the latter two to the former.
Example output, before and after, for the `AssocItemConstraint` change:
```
{"name":"Offset","args":{"angle_bracketed":{"args":[],"constraints":[]}},"binding":{...}}
{"name":"Offset","args":null,"binding":{...}}
```
Example output, before and after, for the `Type::QualifiedPath` change:
```
{"qualified_path":{"name":"Offset","args":{"angle_bracketed":{"args":[],"constraints":[]}}, ...}}
{"qualified_path":{"name":"Offset","args":null, ...}}
```
This reduces JSON output size, but not by much (e.g. 0.5%), because
`AssocItemConstraint` and `Type::QualifiedPath` are uncommon.
A path without generic args, like `Reader`, currently has JSON produced
like this:
```
{"path":"Reader","id":286,"args":{"angle_bracketed":{"args":[],"constraints":[]}}}
```
Even though `types::Path::args` is `Option` and allows for "no args",
instead it gets represented as "empty args". (More like `Reader<>` than
`Reader`.)
This is due to a problem in `clean::Path::from_clean`. It only produces
`None` if the path is an empty string. This commit changes it to also
produce `None` if there are no generic args. The example above becomes:
```
{"path":"Reader","id":286,"args":null}
```
I looked at a few examples and saw this reduce the size of the JSON
output by 3-9%.
The commit also adds an assertion that non-final segments don't have any
generics; something the old code was implicitly relying on.
Note: the original sin here is that `clean::PathSegment::args` is not an
`Option`, unlike `{ast,hir}::PathSegment::args`. I want to fix that, but
it can be done separately.
Adjust `with_generic_param_rib`.
Currently all of its call sites construct a `LifetimeRibKind::Generics` value, which `with_generic_param_rib` then deconstructs (and panics if it's a different `LifetimeRibKind` variant).
This commit makes the code simpler and shorter: the call sites just pass in the three values and `with_generic_param_rib` constructs the `LifetimeRibKind::Generics` value from them.
r? `@petrochenkov`
Add CI check to ensure that rustdoc JSON `FORMAT_VERSION` is correctly updated
Follow-up of https://github.com/rust-lang/rust/pull/142601.
Tested it locally with: `BASE_COMMIT=1bb335244c311a07cee165c28c553c869e6f64a9 src/ci/docker/host-x86_64/mingw-check-1/validate-rustdoc-json-format-version-update.sh` (where `BASE_COMMIT` value was the commit before I made a wrong change with the `FORMAT_VERSION` update).
This is a first version. I plan to send a follow-up to also ensure that `FORMAT_VERSION` is updated if any code change is done in `rustdoc-json-types`. For that I just need to check that a line not starting with `/` and not an empty line was updated. Fun times with `grep` ahead. :')
cc `@aDotInTheVoid`
r? `@nnethercote`
Reason about borrowed classes in CopyProp.
Fixes https://github.com/rust-lang/rust/issues/141122
The current implementation of `CopyProp` avoids unifying two borrowed locals, as this would change the result of address comparison.
However, the implementation was inconsistent with the general algorithm, which identifies equivalence classes of locals and then replaces all locals by a single representative of their equivalence class.
This PR fixes it by forbidding the unification of two *classes* if any of those contain a borrowed local.
Marks ADT live if it appears in pattern
Marks ADT live if it appears in pattern, it implies the construction of the ADT.
1. Then we can detect unused private ADTs impl `Default`, without special logics for `Default` and other std traits.
2. We can also remove `rustc_trivial_field_reads` on `Default`, and the logic in `should_ignore_item` (introduced by rust-lang/rust#126302).
Fixesrust-lang/rust#120770
Extracted from rust-lang/rust#128637.
r? `@petrochenkov`
Insert parentheses around binary operation with attribute
Fixes the bug found by `@fmease` in https://github.com/rust-lang/rust/pull/134661#pullrequestreview-2538983253.
Previously, `-Zunpretty=expanded` would expand this program as follows:
```rust
#![feature(stmt_expr_attributes)]
#![allow(unused_attributes)]
macro_rules! group {
($e:expr) => {
$e
};
}
macro_rules! extra {
($e:expr) => {
#[allow()] $e
};
}
fn main() {
let _ = #[allow()] 1 + 1;
let _ = group!(#[allow()] 1) + 1;
let _ = 1 + group!(#[allow()] 1);
let _ = extra!({ 0 }) + 1;
let _ = extra!({ 0 } + 1);
}
```
```console
let _ = #[allow()] 1 + 1;
let _ = #[allow()] 1 + 1;
let _ = 1 + #[allow()] 1;
let _ = #[allow()] { 0 } + 1;
let _ = #[allow()] { 0 } + 1;
```
The first 4 statements are the correct expansion, but the last one is not. The attribute is supposed to apply to the entire binary operation, not only to the left operand.
After this PR, the 5th statement will expand to:
```console
let _ = #[allow()] ({ 0 } + 1);
```
In the future, as some subset of `stmt_expr_attributes` approaches stabilization, it is possible that we will need to do parenthesization for a number of additional cases depending on the outcome of https://github.com/rust-lang/rust/issues/127436. But for now, at least this PR makes the pretty-printer align with the current behavior of the parser.
r? fmease
Bringing `rustc_rayon_core` in tree as `rustc_thread_pool`
This PR moves [`rustc_rayon_core`](5fadf44/rayon-core) from commit `5fadf44` as suggested in [this zulip thread](https://rust-lang.zulipchat.com/#narrow/channel/187679-t-compiler.2Fparallel-rustc/topic/Bringing.20.60rustc_rayon_core.60.20in.20tree). I tried to split the work into separate commits so it is easy to review. The first commit is a simple copy and paste from the fork, and subsequent changes were made to use the new crate and to ensure the new crate complies with different format and lint expectations.
**Call-out:** I was also wondering if I need to make any further changes to accommodate licensing requirements.
r? oli-obk
If a reborrow is itself borrowed mutably, do not propose to replace it
by the original reference.
Fixes: rust-lang/rust-clippy#14934
changelog: [`borrow_deref_ref`]: do not propose replacing a reborrow by
the original reference if the reborrow is itself mutably borrowed
For example, adding `*` in front of `*expression` is best shown as
`**expression` rather than `*(*expression)`.
This is not perfect, as it checks whether the operator is already a
prefix of the expression, but it is better than it was before. For
example, `&`+`&mut x` will get `&&mut x` but `&mut `+`&x` will get `&mut
(&x)` as it did before this change.
changelog: none
Optimize `needless_doctest_main`, make it short-circuit, make sure that
we don't spin up a new compiler on EVERY code block.
---
The old implementation was creating a new compiler, new parser, new
thread, new SessionGlobals, new everything for each code block. No
matter if they actually didn't even contain `fn main()` or anything
relevant.
On callgrind, seems that we're reducing about a 6.7242% de cycle count
(which turns out to be a 38 million instruction difference, great!).
Benchmarked in `bumpalo-3.16.0`. Also on bumpalo we spawn 78 less
threads. This moves `SessionGlobals::new` from the top time-consuming
function by itself in some benchmarks, into one not even in the top 500.
Also, populate the test files.
changelog:[`needless_doctest_main`]: Avoid spawning so many threads in
unnecessary circumstances
The lint will note `the end suggestion probably needs some adjustments
to use the expression result correctly` when the expr's is not unit. So
I extend this note to also appear when the expr is in an assignment.
changelog: [`branches_sharing_code`] fix misleading suggestions when in
assignment
