-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Rollup of 8 pull requests #125960
Rollup of 8 pull requests #125960
Conversation
While the semantic intent of a OnceCell/OnceLock is that it can only be written to once (upon init), the fact of the matter is that both these types offer a `take(&mut self) -> Option<T>` mechanism that, when successful, resets the cell to its initial state, thereby technically allowing it to be written to again. Despite the fact that this can only happen with a mutable reference (generally only used during the construction of the OnceCell/OnceLock), it would be incorrect to say that the type itself as a whole categorically prevents being initialized or written to more than once (since it is possible to imagine an identical type only without the `take()` method that actually fulfills that contract). To clarify, change "that cannot be.." to "that nominally cannot.." and add a note to OnceCell about what can be done with an `&mut Self` reference.
…g you see on the page.
… are unused, just the number of entries is checked. The indices will be used in a follow-up commit
…, r=ehuss Add tracking issue and unstable book page for `"vectorcall"` ABI Originally added in 2015 by rust-lang#30567, the Windows `"vectorcall"` ABI didn't have a tracking issue until now. Tracking issue: rust-lang#124485
Change pedantically incorrect OnceCell/OnceLock wording While the semantic intent of a OnceCell/OnceLock is that it can only be written to once (upon init), the fact of the matter is that both these types offer a `take(&mut self) -> Option<T>` mechanism that, when successful, resets the cell to its initial state, thereby [technically allowing it to be written to again](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=415c023a6ae1ef35f371a2d3bb1aa735) Despite the fact that this can only happen with a mutable reference (generally only used during the construction of the OnceCell/OnceLock), it would be incorrect to say that the type itself as a whole *categorically* prevents being initialized or written to more than once (since it is possible to imagine an identical type only without the `take()` method that actually fulfills that contract). To clarify, change "that cannot be.." to "that nominally cannot.." and add a note to OnceCell about what can be done with an `&mut Self` reference. ```@rustbot``` label +A-rustdocs
…, r=BoxyUwU Avoid follow-up errors if the number of generic parameters already doesn't match fixes rust-lang#125604 best reviewed commit-by-commit
…huss ARM Target Docs Update Updates the ARM target docs, drawing more attention to the `arm-none-eabi` target group by placing all targets *within* that group as a sub-list in the Table of Contents. Also updates the `armv4t-none-eabi` page (maintainer signoff: I'm that target's maintainer) to clarify that the page covers the arm version and the thumb version of the target, but that the target group page has the full info because there's nothing really specific to say for those targets.
Align `Term` methods with `GenericArg` methods, add `Term::expect_*` * `Term::ty` -> `Term::as_type`. * `Term::ct` -> `Term::as_const`. * Adds `Term::expect_type` and `Term::expect_const`, and uses them in favor of `.ty().unwrap()`, etc. I could also shorten these to `as_ty` and then do `GenericArg::as_ty` as well, but I do think the `as_` is important to signal that this is a conversion method, and not a getter, like `Const::ty` is. r? types
…=petrochenkov Handle no values cfgs with `--print=check-cfg` This PR fix a bug with `--print=check-cfg`, where no values cfgs where not printed since we only printed cfgs that had at least one values. The representation I choose is `CFG=`, since it doesn't correspond to any valid config, it also IMO nicely complements the `values()` (to indicate no values). Representing the absence of value by the absence of the value. So for `cfg(feature, values())` we would print `feature=`. I also added the missing tracking issue number in the doc. r? ```@petrochenkov```
…ket-impls, r=GuillaumeGomez rustdoc: add a regression test for a former blanket impl synthesis ICE Fixes rust-lang#119792 (also passes in rust-lang#125907 in case you were wondering). r? rustdoc
Remove stray "this"
@bors r+ rollup=never p=8 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: 27529d5c25 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (85f90a4): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)Results (primary 3.8%, secondary 2.1%)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.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 671.395s -> 673.596s (0.33%) |
Successful merges:
"vectorcall"
ABI #124486 (Add tracking issue and unstable book page for"vectorcall"
ABI)Term
methods withGenericArg
methods, addTerm::expect_*
#125750 (AlignTerm
methods withGenericArg
methods, addTerm::expect_*
)--print=check-cfg
#125818 (Handle no values cfgs with--print=check-cfg
)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup