Skip to content

Rustc pull update #2372

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 31 commits into
base: master
Choose a base branch
from
Open

Rustc pull update #2372

wants to merge 31 commits into from

Conversation

github-actions[bot]
Copy link

@github-actions github-actions bot commented May 5, 2025

Latest update from rustc.

bors and others added 30 commits May 1, 2025 04:11
Add a jobserver proxy to ensure at least one token is always held

This adds a jobserver proxy to ensure at least one token is always held by `rustc`. Currently with `-Z threads` `rustc` can temporarily give up all its tokens, causing `cargo` to spawn additional `rustc` instances beyond the job limit.

The current behavior causes an issue with `cargo fix` which has a global lock preventing concurrent `rustc` instances, but it also holds a jobserver token, causing a deadlock when `rustc` gives up its token. That is fixed by this PR.

Fixes rust-lang/rust#67385.
Fixes rust-lang/rust#133873.
Fixes rust-lang/rust#140093.
…r=bjorn3

shared-generics: Do not share instantiations that contain local-only types

In Zed shared-generics loading takes up a significant chunk of time in incremental build, as rustc deserializes rmeta of all dependencies of a crate. I've recently realized that shared-generics includes all instantiations of some_generic_function in the following snippet:
```rs
pub fn some_generic_function(_: impl Fn()) {}

pub fn non_generic_function() {
	some_generic_function(|| {});
	some_generic_function(|| {});
	some_generic_function(|| {});
	some_generic_function(|| {});
	some_generic_function(|| {});
	some_generic_function(|| {});
	some_generic_function(|| {});
}
```
even though none of these instantiations can actually be created from outside of `non_generic_function`. This is a dummy example, but we do rely on invoking callbacks with FnOnce a lot in our codebase.

This PR makes shared-generics account for visibilities of generic arguments; an item is only considered for exporting if it is reachable from the outside or if all of it's arguments are visible outside of the local crate.

This PR reduces incremental build time for Zed (touch editor.rs scenario) from 12.4s to 10.4s. I'd love to see a perf run if possible; per my checks this PR does not incur new instantiations in downstream crates, so if there'd be perf regressions, I'd expect them to come from newly-introduced visibility checks.
…ions, r=lcnr

Decouple SCC annotations from SCCs

This rewires SCC annotations to have them be a separate, visitor-type data structure. It was broken out of #130227, which needed them to be able to remove unused annotations after computation without recomputing the SCCs themselves.

As a drive-by it also removes some redundant code from the hot loop in SCC construction for a performance improvement.

r? lcnr
chore: remove redundant words in comment

remove redundant words in comment
Refactor `diy_float`

The refactor replaces bespoke algorithms with functions already inside the standard library, improving both codegen and readability.
…rkingjubilee

docs: Add example to `Iterator::take` with `by_ref`

If you want to logically split an iterator after `n` items, you might first discover `take`. Before this change, you'd find that `take` consumes the iterator, and you'd probably be stuck. The answer involves `by_ref`, but that's hard to discover, especially since `by_ref` is a bit abstract and `Iterator` has many methods.

After this change, you'd see the example showing `take` along with `by_ref`, which allows you to continue using the rest of the iterator. `by_ref` had a good example involving `take` already, so this change just duplicates that existing example under `take`.
…ngjubilee

Fix some grammar errors and hyperlinks in doc for `trait Allocator`

I was reading the allocator docs and noticed some weird sentences and missing hyperlink, so I fixed them and made this small PR.

* "while until either" could also be changed to "for a while until either", but I just deleted "while".
* fixed sentence with incorrect "at" and "has/have".
* linked [*currently allocated*] similar to other methods. All other hyperlinks are fine.
…kingjubilee

simd_select_bitmask: the 'padding' bits in the mask are just ignored

Fixes rust-lang/rust#137942: we documented simd_select_bitmask to require the 'padding' bits in the mask (the mask can sometimes be longer than the vector; I am referring to these extra bits as 'padding' here)  to be zero, mostly because nobody felt like doing the research for what should be done when they are non-zero. However, codegen is already perfectly happy just ignoring them, so in practice they can have any value. Some of the intrinsic wrappers in stdarch have trouble ensuring that they are zero. So let's just adjust the docs and Miri to permit non-zero 'padding' bits.

Cc ````@Amanieu```` ````@workingjubilee````
std: mention `remove_dir_all` can emit `DirectoryNotEmpty` when concurrently written into

Closes #139958

The current documentation for `std::fs::remove_dir_all` function does not explicitly mention the error types that may be returned in concurrent scenarios. Specifically, when one thread attempts to remove a directory tree while another thread simultaneously writes files to that directory, the function may return an `io::ErrorKind::DirectoryNotEmpty` error, but this behavior is not clearly mentioned in the current documentation.

r? libs
…eGomez

rustdoc: Fix doctest heuristic for main fn wrapping

Fixes #140412 which regressed in #140220 that I reviewed. As mentioned in rust-lang/rust#140220 (comment), at the time I didn't have the time to re-review its latest changes and should've therefore invalided my previous "r=me" and blocked the PR on another review given the fragile nature of the doctest impl. This didn't happen which is my fault.

Contains some other small changes. Diff best reviewed modulo whitespace.
r? ``@GuillaumeGomez``
Fix handling of LoongArch target features not supported by LLVM 19

Fixes #140455
rustc-dev-guide subtree update

r? ``@ghost``
Clean up "const" situation in format_args!().

This cleans up the "const" situation in the format_args!() expansion/lowering.

Rather than marking the Argument::new_display etc. functions as non-const, this marks the Arguments::new_v1 functions as non-const.

Example expansion/lowering of format_args!() in const:

```rust
// Error: cannot call non-const formatting macro in constant functions
const {
    fmt::Arguments::new_v1( // Now the error is produced here.
        &["Hello, ", "!\n"],
        &[
            fmt::Argument::new_display(&world) // The error used to be produced here.
        ],
    )
}
```
…l_symbol, r=bjorn3

allow `#[rustc_std_internal_symbol]` in combination with `#[naked]`

The need for this came up in rust-lang/compiler-builtins#897, but in general this seems useful and valid to allow.

Based on a quick scan, I don't think changes to the generated assembly are needed.

cc ``@bjorn3``
…or-output, r=clubby789

Improve error output in case `nodejs` or `npm` is not installed for rustdoc-gui test suite

Fixes rust-lang/rust#138134.

It now looks like this:

![Screenshot From 2025-05-01 17-41-12](https://github.com/user-attachments/assets/ae7f2b37-3619-47ff-941d-5d9a7cdd9b6b)

cc ``@kpreid``
Rollup of 12 pull requests

Successful merges:

 - #138703 (chore: remove redundant words in comment)
 - #139186 (Refactor `diy_float`)
 - #139780 (docs: Add example to `Iterator::take` with `by_ref`)
 - #139802 (Fix some grammar errors and hyperlinks in doc for `trait Allocator`)
 - #140034 (simd_select_bitmask: the 'padding' bits in the mask are just ignored)
 - #140062 (std: mention `remove_dir_all` can emit `DirectoryNotEmpty` when concurrently written into)
 - #140420 (rustdoc: Fix doctest heuristic for main fn wrapping)
 - #140460 (Fix handling of LoongArch target features not supported by LLVM 19)
 - #140538 (rustc-dev-guide subtree update)
 - #140544 (Clean up "const" situation in format_args!(). )
 - #140552 (allow `#[rustc_std_internal_symbol]` in combination with `#[naked]`)
 - #140556 (Improve error output in case `nodejs` or `npm` is not installed for rustdoc-gui test suite)

r? `@ghost`
`@rustbot` modify labels: rollup
crashes: more tests

try-job: aarch64-apple
try-job: x86_64-msvc-1
try-job: x86_64-gnu
try-job: dist-i586-gnu-i586-i686-musl
try-job: test-various
perf: delay checking of `#[rustc_no_implicit_autorefs]` in autoref lint

Try to address the regression seen in rust-lang/rust#123239 (comment) by delaying the checking of `#[rustc_no_implicit_autorefs]` on method call.
…king, r=wesleywiser

mono collector: Reduce # of locking while walking the graph

While profiling Zed's dev build I've noticed that while most of the time `upstream_monomorphizations` takes a lot of time in monomorpization_collector, in some cases (e.g. build of `editor` itself) the rest of monomorphization_collector_graph_walk dominates it. Most of the time is spent in collect_items_rec.

This PR aims to reduce the number of locks taking place; instead of locking output MonoItems once per children of current node, we do so once per *current node*. We also get to reuse locks for mentioned and used items. While this commit does not reduce Wall time of Zed's build, it does shave off CPU time (measured with `cargo build -j1`) from 48s to 47s. I've also tested it with parallel frontend against Zed and ripgrep and found no regressions.
Use a closure instead of three chained iterators

Fixes the perf regression from #123948

That PR had chained a third option to the iterator which apparently didn't optimize well
Update hashbrown dependency to unblock ExtractIf improvements

Release notes: https://github.com/rust-lang/hashbrown/releases/tag/v0.15.3

Relevant to me, this release includes rust-lang/hashbrown#616 which unblocks rust-lang/rust#139764.
Set groundwork for proper const normalization

r? lcnr

Updates a lot of our normalization/alias infrastructure to be setup to handle mgca aliases and normalization once const items are represented more like aliases than bodies. Inherent associated consts are still super busted, I didn't update the assertions that IACs the right arg setup because that winds up being somewhat involved to do *before* proper support for normalizing const aliases is implemented.

I dont *intend* for this to have any effect on stable. We continue normalizing via ctfe on stable and the codepaths in `project` for consts should only be reachable with mgca or ace.
and migrate most of remaining `error-pattern`s to it.
compiletest: Support matching on non-json lines in compiler output

and migrate most of remaining `error-pattern`s to it.
Such diagnostics use a new diagnostic kind `RAW`.

Also emit an error for `error-pattern`s that can be replaced with line annotations.
Also remove a number of conditions to check both line annotations and `error-pattern`s in more cases.
Also respect `//@ check-stdout` when collecting "actual errors" for comparing against line annotations.
(A couple of tiny refactorings is also included.)

Continuation of rust-lang/rust#139760.

r? `@jieyouxu`
stabilize ptr::swap_nonoverlapping in const

Closes rust-lang/rust#133668

The blocking issue mentioned there is resolved by documentation. We may in the future actually support such code, but that is blocked on rust-lang/const-eval#72 which is non-trivial to implement. Meanwhile, this completes stabilization of all `const fn` in `ptr`. :)

Here's a version of the problematic example to play around with:
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=6c390452379fb593e109b8f8ee854d2a

Should be FCP'd with both `@rust-lang/libs-api`  and `@rust-lang/lang`  since  `swap_nonoverlapping` is documented to work as an "untyped" operation but due to the limitation mentioned above, that's not entirely true during const evaluation. I expect this limitation will only be hit in niche corner cases, so the benefits of having this function work most of the time outweigh the downsides of users running into this problem. (Note that unsafe code could already hit this limitation before this PR by doing cursed pointer casts, but having it hidden inside `swap_nonoverlapping` feels a bit different.)
…rk-Simulacrum

Use target-cpu=z13 on s390x codegen const vector test

The default s390x cpu(z10) does not have vector support. Setting target-cpu at least to z13 enables vectorisation for s390x architecture and makes the test pass.
Rollup of 6 pull requests

Successful merges:

 - #137280 (stabilize ptr::swap_nonoverlapping in const)
 - #140457 (Use target-cpu=z13 on s390x codegen const vector test)
 - #140619 (Small adjustments to `check_attribute_safety` to make the logic more obvious)
 - #140625 (Suggest `retain_mut` over `retain` as `Vec::extract_if` alternative)
 - #140627 (Allow linking rustc and rustdoc against the same single tracing crate)
 - #140630 (Async drop source info fix for proxy-drop-coroutine)

r? `@ghost`
`@rustbot` modify labels: rollup
@rustbot rustbot closed this May 5, 2025
@rustbot rustbot reopened this May 5, 2025
@tshepang
Copy link
Member

tshepang commented May 5, 2025

will let this one wait for thu automated pull, given how tiny it is

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants