-
Notifications
You must be signed in to change notification settings - Fork 545
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
github-actions
wants to merge
31
commits into
master
Choose a base branch
from
rustc-pull
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Rustc pull update #2372
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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:  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
Clippy subtree update r? `@Manishearth`
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
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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Latest update from rustc.