Rollup of 6 pull requests #135540
Merged
Rollup of 6 pull requests #135540
Conversation
This file contains 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
It's never overridden, so it shouldn't be on the trait.
The two implementations were identical, so there's no need to use a trait method.
The new code is more explicit and avoids trait magic that added needless complexity to this part of rustdoc.
This reverts commit 0747f28.
Thereby, we also allow accessing thread::current before main: as the runtime no longer tries to install its own handle, this will no longer trigger an abort. Rather, the name returned from name will only be "main" after the runtime initialization code has run, but I think that is acceptable. This new approach also requires some changes to the signal handling code, as calling `thread::current` would now allocate when called on the main thread, which is not acceptable. I fixed this by adding a new function (`with_current_name`) that performs all the naming logic without allocation or without initializing the thread ID (which could allocate on some platforms).
Originally authored by GnomedDev
This incorporates all the backwards-compatible changes for the 2024 Edition. There will also be a follow-on PR to land revisions to the new chapter on async so it can be as ready as possible when officially released with 1.85 and the 2024 Edition. Additionally, there are a few other, non-backward-compatible, changes (largely around `use<..>`) we can only land using the stable edition, which we may or may not be able to land in 1.85 by using the beta toolchain in the example code. Those may or may not be ported over, depending on how that does or does not play with the infrastructure.
…ge when the unstable module name is used
Signed-off-by: onur-ozkan <[email protected]>
std: lazily allocate the main thread handle rust-lang#123550 eliminated the allocation of the main thread handle, but at the cost of greatly increased complexity. This PR proposes another approach: Instead of creating the main thread handle itself, the runtime simply remembers the thread ID of the main thread. The main thread handle is then only allocated when it is used, using the same lazy-initialization mechanism as for non-runtime use of `thread::current`, and the `name` method uses the thread ID to identify the main thread handle and return the correct name ("main") for it. Thereby, we also allow accessing `thread::current` before main: as the runtime no longer tries to install its own handle, this will no longer trigger an abort. Rather, the name returned from `name` will only be "main" after the runtime initialization code has run, but I think that is acceptable. This new approach also requires some changes to the signal handling code, as calling `thread::current` would now allocate when called on the main thread, which is not acceptable. I fixed this by adding a new function (`with_current_name`) that performs all the naming logic without allocation or without initializing the thread ID (which could allocate on some platforms). Reverts rust-lang#123550, CC ``@GnomedDev``
…-unstable, r=davidtwco deprecate `std::intrinsics::transmute` etc, use `std::mem::*` instead The `rustc_allowed_through_unstable_modules` attribute lets users call `std::mem::transmute` as `std::intrinsics::transmute`. The former is a reexport of the latter, and for a long time we didn't properly check stability for reexports, so making this a hard error now would be a breaking change for little gain. But at the same time, `std::intrinsics::transmute` is not the intended path for this function, so I think it is a good idea to show a deprecation warning when that path is used. This PR implements that, for all the functions in `std::intrinsics` that carry the attribute. I assume this will need ``@rust-lang/libs-api`` FCP.
…omez rustdoc: Remove `AttributesExt` trait magic that added needless complexity The new code is more explicit and avoids trait magic that added needless complexity to this part of rustdoc.
…leteness, r=lcnr Prefer lower `TraitUpcasting` candidates in selection Fixes rust-lang#135463. The underlying cause is this ambiguity, but it's more clear (and manifests as a coercion error, rather than a MIR validation error) when it's written the way I did in the UI test. Sorry this is cursed r? lcnr
…table, r=ehuss TRPL: incorporate all backward-compatible Edition changes This incorporates all the backwards-compatible changes for the 2024 Edition on stable. There will also be a follow-on PR to land revisions to the new chapter on async so it can be as ready as possible when officially released with 1.85 and the 2024 Edition. Additionally, there are a few other, non-backward-compatible, changes (largely around `use<..>`) we can only land using the stable edition, which we may or may not be able to land in 1.85 by using the beta toolchain in the example code. Those may or may not be ported over, depending on how that does or does not play with the infrastructure. There is also an accompanying PR, rust-lang#135508, to land these changes on `beta` so they can go out with 1.85 and the Edition release.
remove outdated FIXME rust-lang#134967 already fixed this.
rustbot
added
O-unix
|
@bors r+ p=6 rollup=never |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: 27f336106d In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
This was referenced Jan 15, 2025
|
Finished benchmarking commit (419b3e2): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary 1.6%, secondary 0.8%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (primary -0.7%, secondary -4.3%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeResults (primary 0.1%, secondary 0.6%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Bootstrap: 763.057s -> 763.488s (0.06%) |
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.
Successful merges:
std::intrinsics::transmuteetc, usestd::mem::*instead #135003 (deprecatestd::intrinsics::transmuteetc, usestd::mem::*instead)AttributesExttrait magic that added needless complexity #135428 (rustdoc: RemoveAttributesExttrait magic that added needless complexity)TraitUpcastingcandidates in selection #135498 (Prefer lowerTraitUpcastingcandidates in selection)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup