Rustc pull update - #2203
Open
workflows-stdarch[bot] wants to merge 33 commits into
Open
Conversation
…rtdev stdarch subtree update Subtree update of `stdarch` to 50afa9f. Created using https://github.com/rust-lang/josh-sync. r? @ghost
Simplify the unwind crate Use cfg_select! and unify type definitions.
…llot Stop using prefix_tys *This is a member of a patch series to replace rust-lang/rust#135527.* This function hints at an early commitment to coroutine memory layout. We should not give promises on how upvars are allocated.
…-Simulacrum triagebot: cc miri on any special-casing of miri in the standard library --- Blocked until rust-lang/triagebot#2462 is merged and deployed.
Apply `#[diagnostic::opaque]` to macros expanding to built-in syntax For context, thin wrapper macros expanding to built-in syntax `builtin # SYNTAX(…)` (internal feature `builtin_syntax`) is an alternative to built-in macros (`#[rustc_builtin_macro]`) for introducing new syntax constructs that takes slightly less code to implement in the compiler (since one doesn't need to write boiler-plate expanders, see RUST-122806 for example). However, one disadvantage of that approach is the fact that the thin wrapper macro is a normal macro and is thus considered "interesting" wrt. macro backtraces. The fact that it expands to `builtin # SYNTAX(…)` should be considered an implementation detail and thus these macros should be considered opaque. I've applied `#[diagnostic::opaque]` (rust-lang/rust#158608) to all of these macros which successfully suppresses diagnostic notes of the form `` this error originates in the macro `SYNTAX` (…) ``. Well, it doesn't actually omit the expansion from the macro backtrace when `-Zmacro-backtrace` is passed which was surprising but seems intentional looking at the linked PR. Still, this is better than nothing. r? @mejrs
…nthey implement `const_binary_search` tracking issue: rust-lang/rust#159532 This makes unstably `const` the following public api: `core::slice::binary_search` `core::slice::binary_search_by` `core::slice::binary_search_by_key` `core::slice::partition_point` Happy to make a tracking issue if these are acceptable.
…uwer Rollup of 6 pull requests Successful merges: - rust-lang/rust#159517 (stdarch subtree update) - rust-lang/rust#159010 (Simplify the unwind crate) - rust-lang/rust#156650 (Stop using prefix_tys) - rust-lang/rust#159152 (triagebot: cc miri on any special-casing of miri in the standard library) - rust-lang/rust#159522 (Apply `#[diagnostic::opaque]` to macros expanding to built-in syntax) - rust-lang/rust#159528 (implement `const_binary_search`)
perf: dep_graph: deduplicate task reads with an epoch-filtered index recorder Follow up of rust-lang/rust#158794 During this PR we compared three variants to replace the hashset for tracking the seen set of reads: 1. epoch filter with u32 slots: instruction count -1.7%, but max-RSS +2.6% 1. bitset: instruction count -0.6%. I was able to make a faster version of this by avoiding the resize checks in `GrowableBitSet`, but it was always slower than the epoch filter because the seen items need to be cleared after use. 1. epoch filter with u8 slots: instruction count -1.6%, max-RSS neutral. This seems to have the best trade-off and is now the current change.
…=lcnr Get rid of `StructurallyRelateAliases` Part of rust-lang/rust#155345 Finally we can get rid of the last use of `StructurallyRelateAliases::Yes`. r? lcnr
Replace weak only lang items with a custom attribute When I added the `invalid_runtime_symbol_definitions` and `suspicious_runtime_symbol_definitions` lints in rust-lang/rust#155521 I added the concept of "weak only" lang item. It's a `LangItem` that has no implementation, this is useful because the `core` symbols where not directly called, they were inserted by the compiler. This mechanism work well, but T-lang [approved](rust-lang/rust#158522 (comment)) the extension to "all extern functions referenced by the standard library", which makes the lang item approach impractical as we needs to update 5 files just to declare them. I'm not sure we can ask library contributor to do the dance for each `extern "C"` functions. But the most problematic thing is that many extern functions in `std` come from `libc` not `std`, and adding lang items there is just no feasible I think. Instead this PR proposed that we introduce a proper mechanism for them by adding a attribute `#[rustc_canonical_symbol = "..."]`, which is encoded and decoded in `rmeta` like lang items and diagnostics items. This simplifies the declaration as we only need to put the attribute to be effective `#[rustc_canonical_symbol = "open"]`. It also opens up many possibilities (none implemented here) like putting them on `use` statements (so we don't need to modify `libc`) or having the attribute be placed on a module. The table may also be useful on it's own if we want someday to do it for all crates, not just the standard library. Follow up to rust-lang/rust#155521 and rust-lang/rust#158522
…henkov Resolve: more preperation work for parallelizing the import resolution loop This is basically rust-lang/rust#158845 but we do not: - actually use `par_slice` because: - we do not migrate `CmRefCell` to use `RwLocks` (yet) because of perf reasons. The resolution loop is now in place instead of recollecting indeterminate imports. r? @petrochenkov
Apply RemoveNoopLandingPads post-monomorphization On Cargo this cuts ~5% of the LLVM IR lines we generate (measured with -Cno-prepopulate-passes). Closes rust-lang/rust#159399.
…leywiser,scottmcm Closures inherit #[optimize] from the enclosing function by default. Tracking issue: rust-lang/rust#54882 Stabilization PR: rust-lang/rust#157273
…twco Fix `bool` calling convention for aarch64, etc. We have been making a broad assumption about the way `bool` should be handled that *may* be correct for Rust calling Rust but is wildly incorrect for cross-language FFI calls. The ABI of `bool` is generally poorly-specified in any C psABI, and often deliberately allows for deviation after the first 8 bits. This has surfaced as a bug that can corrupt Rust programs on aarch64, but it is a potential latent bug when it comes to every ABI. The simplest solution is to simply stop applying the special case when generating `bool`'s ArgAttributes. This yields control to the later ABI implementations, which may then sign or zero extend the `bool` (or not) according to their needs.
bootstrap: update cc-rs to `1.2.62` * Removes deprecated `static_flag` build methods
Type fallback refactorings - Don't merge different kinds of infer variables into `Ty` before matching them back - Do fallback only on root vars (this is semantically equivalent to what we currently do; unifying any of the infer vars from the same equivalence class necesserily affects all of them) (this makes rust-lang/rust#159003 a bit less hacky though) - Do some simplification that has been allowed by the previous changes cc @lcnr
[rustdoc] Do not take `doc(cfg())` into account when filtering doctests Part of rust-lang/rust#147033. Because it was using the `extract_cfg_from_attrs` common function, it was taking into account the `doc(cfg())` attributes the same as if they were a `cfg`. I didn't mark this PR as "fix" because I didn't handle the case of the doctest not being marked as ignored because I'm not sure if we should revisit the fact that we ignore these doctests or if we should just mark them as ignored (because of `target_feature(enable = "...")`). Setting @fmease as reviewer as they are likely the only one with context about this issue. 😆 r? @fmease
rustc_llvm: Emit module summaries when using -Clto=fat Currently, module summaries are only emitted with thin lto. If we would link full/fat lto'd rust code against lto'd c++ code built with CFI (or WPD), those passes would fail during the link step because the participating rust modules are missing module summaries. Rust code does not know at compile-time if it would be participating in some special link which may require module summaries, so this PR ensures module summaries are unconditionally emitted for full/fat lto, just like with thin lto. The WriteBitcodeToFile function just invokes the normal BitcodeWriterPass under the hood, but doesn't provide a way to set the argument for emitting module summaries. So this patch just adds the pass directly and sets that argument. This is a rebase of @PiJoules's rust-lang/rust#158099, which also should fix up the tests with the gcc tools.
Update rustc-perf submodule To bring in rust-lang/rustc-perf#2520, which should unblock rust-lang/rust#160527.
…oli-obk treat no_mangle_generic_items as hard error instead of lint warning Reference PR: - rust-lang/reference#1904 In rust-lang/miri#4929 (comment), rustc should reject the no_mangled generic function. This PR treat is as a hard error
Fix, simplify, and document doc meta finalize mode Follow up rust-lang/rust#159415 (comment) Get rid of the mode where you can finalize the CCI and generate more docs at the same time. It isn't used in Cargo, and probably won't be used elsewhere? Fixes a bug where the crate index, settings page, and help page aren’t generated at finalize time. Update documentation. Move CCI tests to run-make, so that we can test the finalize step’s CLI.
Add CoerceShared field-wise reborrow WF checks This PR attempts to add a well-formedness check for CoerceShared. Split out of rust-lang/rust#157101 r? @aapoalas
Add Enzyme bugfix to support rust+llvm23
…nia-e Reorder the methods in `#[rustc_must_implement_one_of]` So that their order will be the preferred order for implementations (assuming implementing `read_buf()` is better), like @joshtriplett said in rust-lang/rust#106643 (comment). r? libs
… r=lqd Revert "codegen_ssa: no dbginfo for scalable vec local w/ `-O0`" This partially reverts commit ebe72104f00ca57e02f7ac70d78089727d5462b5 (it keeps the tests), from rust-lang/rust#158088. The workaround in that patch is no longer necessary with the upgrade to LLVM 23 in rust-lang/rust#158734. I've confirmed that the stdarch tests also continue passing with this patch applied. r? @lqd
…useZ4 Re-enable bool indexing assembly test for LLVM 23 fixes rust-lang/rust#160521 Follow-up rust-lang/rust#159977
… r=mejrs Remove `OnDuplicate::Custom` It was only used for one attribute, where it was not particularly helpful
…au,fmease [rustdoc] Create output file after we checked that the standalone markdown file is valid This PR makes the creation of the output (HTML) file after we checked that the input markdown is valid to prevent the output file content to be truncated ([`File::create` doc](https://doc.rust-lang.org/nightly/std/fs/struct.File.html#method.create)) in any case. r? @Urgau
…uwer Rollup of 12 pull requests Successful merges: - rust-lang/rust#159014 ([rustdoc] Do not take `doc(cfg())` into account when filtering doctests) - rust-lang/rust#159029 (rustc_llvm: Emit module summaries when using -Clto=fat) - rust-lang/rust#160574 (Update rustc-perf submodule) - rust-lang/rust#154585 (treat no_mangle_generic_items as hard error instead of lint warning) - rust-lang/rust#159473 (Fix, simplify, and document doc meta finalize mode) - rust-lang/rust#157489 (Add CoerceShared field-wise reborrow WF checks) - rust-lang/rust#160532 (Add Enzyme bugfix to support rust+llvm23) - rust-lang/rust#160545 (Reorder the methods in `#[rustc_must_implement_one_of]`) - rust-lang/rust#160558 (Revert "codegen_ssa: no dbginfo for scalable vec local w/ `-O0`") - rust-lang/rust#160566 (Re-enable bool indexing assembly test for LLVM 23) - rust-lang/rust#160569 (Remove `OnDuplicate::Custom`) - rust-lang/rust#160576 ([rustdoc] Create output file after we checked that the standalone markdown file is valid)
…enkov perf: Lock-free root fast paths for hygiene queries `normalize_to_macros_2_0`, `normalize_to_macro_rules` and `outer_expn_is_descendant_of` take the `HygieneData` lock even for the root syntax context, the common case, where the answer is fixed: the root normalizes to itself, and everything descends from the root expansion. This PR avoids the lock, like the existing fast paths in `ExpnId::is_descendant_of`.
This updates the rust-version file to f73951df0a5566d94d13b7954acd9f4ab1fa3734.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: rust-lang/rust@f73951d Filtered ref: 2c51139 Upstream diff: rust-lang/rust@fcbe791...f73951d This merge was created using https://github.com/rust-lang/josh-sync.
Collaborator
|
Thanks for the pull request, and welcome! The Rust Project is excited to review your changes, and you should hear from @adamgemmell (or someone else) some time within the next two weeks. Why was this reviewer chosen?The reviewer was selected based on:
|
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
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.