-
Notifications
You must be signed in to change notification settings - Fork 13k
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 #122778
Closed
Closed
Rollup of 8 pull requests #122778
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
static libraries with ar_archive_writer Fixes rust-lang#107495
SeqCst is unnecessary here.
SeqCst is unnecessary here.
Relaxed is enough here.
SeqCst is unnecessary.
Relaxed is enough to make sure this `swap` results in `true` only once.
No need for SeqCst. Release+Acquire is the right memory ordering for a mutex.
SeqCst is unnecessary here.
SeqCst is unnecessary here.
SeqCst is unnecessary. Release+Acquire is the right ordering for a mutex.
Relaxed is enough to ensure fetch_add(1) returns each integer exactly once.
SeqCst is unnecessary. Release+Acquire is the right ordering for a mutex.
The SeqCst wasn't synchronizing with anything. Relaxed is enough.
rustc is just one tool/executable, even if at the center of the toolchain
These assertions detect situations where a BCB node would have both a physical counter and one or more in-edge counters/expressions. For most BCBs that situation would indicate an implementation bug. However, it's perfectly fine in the case of a BCB having an edge that loops back to itself. Given the complexity and risk involved in fixing the assertions, and the fact that nothing relies on them actually being true, this patch just removes them instead.
SeqCst isn't necessary in any of these cases.
Relaxed is enough to have fetch_add(1) return each value only once (until it wraps around).
Relaxed memory ordering is fine because spawn()/join() already provides all the synchronization we need.
Relaxed is enough here. Synchronization is done by the mutex.
Simplify key-based thread locals This PR simplifies key-based thread-locals by: * unifying the macro expansion of `const` and non-`const` initializers * reducing the amount of code in the expansion * simply reallocating on recursive initialization instead of going through `LazyKeyInner` * replacing `catch_unwind` with the shared `abort_on_dtor_unwind` It does not change the initialization behaviour described in rust-lang#110897.
…iler-errors pattern analysis: add a custom test harness There are two features of the pattern analysis code that are hard to test: the newly-added pattern complexity limit, and the computation of arm intersections. This PR adds some crate-specific tests for that, including an unmaintainable but pretty macro to help construct patterns. r? ``@compiler-errors``
…thercote Use same file permissions for ar_archive_writer as the LLVM archive writer This is required to switch to ar_archive_writer in the future without regressions. In addition to this PR support for reading thin archives needs to be added (rust-lang#107407) to fix all known regressions. Fixes rust-lang#107495
Relax SeqCst ordering in standard library. Every single SeqCst in the standard library is unnecessary. In all cases, Relaxed or Release+Acquire was sufficient. As I [wrote](https://marabos.nl/atomics/memory-ordering.html#common-misconceptions) in my book on atomics: > [..] when reading code, SeqCst basically tells the reader: "this operation depends on the total order of every single SeqCst operation in the program," which is an incredibly far-reaching claim. The same code would likely be easier to review and verify if it used weaker memory ordering instead, if possible. For example, Release effectively tells the reader: "this relates to an acquire operation on the same variable," which involves far fewer considerations when forming an understanding of the code. > > It is advisable to see SeqCst as a warning sign. Seeing it in the wild often means that either something complicated is going on, or simply that the author did not take the time to analyze their memory ordering related assumptions, both of which are reasons for extra scrutiny. r? `@Amanieu` `@joboet`
use more accurate terminology rustc is just one tool/executable, even if at the center of the toolchain
coverage: Remove incorrect assertions from counter allocation These assertions detect situations where a BCB node (in the coverage graph) would have both a physical counter and one or more in-edge counters/expressions. For most BCBs that situation would indicate an implementation bug. However, it's perfectly fine in the case of a BCB having an edge that loops back to itself. Given the complexity and risk involved in fixing the assertions, and the fact that nothing relies on them actually being true, this patch just removes them instead. Fixes rust-lang#122738. ``@rustbot`` label +A-code-coverage
…ng-usize-max, r=Nilstrieb Add `usize::MAX` arg tests for Vec Tests to prevent recurrence of the UB from the rust-lang#122760 issue. I skipped the `with_capacity`, `drain`, `reserve`, etc. APIs because they actually had a good assortment of tests earlier in the same file. r? Nilstrieb
…li-obk Rename `hir::Let` into `hir::LetExpr` As discussed on [zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Improve.20naming.20of.20.60ExprKind.3A.3ALet.60.3F). r? ``@Zalathar``
rustbot
added
O-unix
Operating system: Unix-like
O-wasm
Target: WASM (WebAssembly), http://webassembly.org/
O-windows
Operating system: Windows
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
T-bootstrap
Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
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.
rollup
A PR which is a rollup
labels
Mar 20, 2024
@bors r+ p=5 rollup=never |
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
Mar 20, 2024
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 20, 2024
…llaumeGomez Rollup of 8 pull requests Successful merges: - rust-lang#122494 (Simplify key-based thread locals) - rust-lang#122644 (pattern analysis: add a custom test harness) - rust-lang#122723 (Use same file permissions for ar_archive_writer as the LLVM archive writer) - rust-lang#122729 (Relax SeqCst ordering in standard library.) - rust-lang#122740 (use more accurate terminology) - rust-lang#122764 (coverage: Remove incorrect assertions from counter allocation) - rust-lang#122765 (Add `usize::MAX` arg tests for Vec) - rust-lang#122776 (Rename `hir::Let` into `hir::LetExpr`) r? `@ghost` `@rustbot` modify labels: rollup
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
and removed
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
labels
Mar 20, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
O-unix
Operating system: Unix-like
O-wasm
Target: WASM (WebAssembly), http://webassembly.org/
O-windows
Operating system: Windows
rollup
A PR which is a rollup
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
T-bootstrap
Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
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.
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:
usize::MAX
arg tests for Vec #122765 (Addusize::MAX
arg tests for Vec)hir::Let
intohir::LetExpr
#122776 (Renamehir::Let
intohir::LetExpr
)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup