Skip to content
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

Merged
merged 30 commits into from
Jun 4, 2024
Merged

Rollup of 8 pull requests #125960

merged 30 commits into from
Jun 4, 2024

Conversation

jieyouxu
Copy link
Member

@jieyouxu jieyouxu commented Jun 4, 2024

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

beetrees and others added 30 commits April 28, 2024 19:27
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.
… 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
@rustbot rustbot added O-unix Operating system: Unix-like S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) rollup A PR which is a rollup labels Jun 4, 2024
@jieyouxu
Copy link
Member Author

jieyouxu commented Jun 4, 2024

@bors r+ rollup=never p=8

@bors
Copy link
Contributor

bors commented Jun 4, 2024

📌 Commit a04a603 has been approved by jieyouxu

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 4, 2024
@bors
Copy link
Contributor

bors commented Jun 4, 2024

⌛ Testing commit a04a603 with merge 85f90a4...

@bors
Copy link
Contributor

bors commented Jun 4, 2024

☀️ Test successful - checks-actions
Approved by: jieyouxu
Pushing 85f90a4 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jun 4, 2024
@bors bors merged commit 85f90a4 into rust-lang:master Jun 4, 2024
7 checks passed
@rustbot rustbot added this to the 1.80.0 milestone Jun 4, 2024
@rust-timer
Copy link
Collaborator

📌 Perf builds for each rolled up PR:

PR# Message Perf Build Sha
#124486 Add tracking issue and unstable book page for `"vectorcall"… 1be3e648b07bdf69590fea82f3f37616d2f4243a (link)
#125504 Change pedantically incorrect OnceCell/OnceLock wording e7cfec2e7ead15d83bc4368aa5b8857db91b49dd (link)
#125608 Avoid follow-up errors if the number of generic parameters … f1babe710d9c55188c8951794f9af4a3bdf797e3 (link)
#125690 ARM Target Docs Update 3c6ffe901181a5046c87e6442c4f2aa3b8390fc5 (link)
#125750 Align Term methods with GenericArg methods, add `Term::… c090fe60b382d8742ad90949883b56d89be04396 (link)
#125818 Handle no values cfgs with --print=check-cfg ecb15ab20b9ef13f90724f690ede6e5a14ce60db (link)
#125909 rustdoc: add a regression test for a former blanket impl sy… 1e71efa2650bda979a490240528f1ea6172e4195 (link)
#125919 Remove stray "this" 1291b2255355963a875ea68565ae7cda67c94292 (link)

previous master: 27529d5c25

In the case of a perf regression, run the following command for each PR you suspect might be the cause: @rust-timer build $SHA

@jieyouxu jieyouxu deleted the rollup-1s7f6lr branch June 4, 2024 11:55
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (85f90a4): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.2% [-2.2%, -2.2%] 1
All ❌✅ (primary) - - 0

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.

mean range count
Regressions ❌
(primary)
3.8% [3.3%, 4.3%] 2
Regressions ❌
(secondary)
3.2% [2.3%, 5.2%] 4
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.4% [-2.4%, -2.4%] 1
All ❌✅ (primary) 3.8% [3.3%, 4.3%] 2

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 671.395s -> 673.596s (0.33%)
Artifact size: 319.04 MiB -> 318.88 MiB (-0.05%)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. O-unix Operating system: Unix-like rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver)
Projects
None yet
Development

Successfully merging this pull request may close these issues.