Rollup of 3 pull requests #70676
Closed
Rollup of 3 pull requests #70676
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
Before this commit `-C codegen-units` would just get silently be ignored if `-C incremental` was specified too. After this commit one can control the number of codegen units generated during incremental compilation. The default is rather high at 256, so most crates won't see a difference unless explicitly opting into a lower count.
…atsakis Make the rustc respect the `-C codegen-units` flag in incremental mode. This PR implements (the as of yet unapproved) major change proposal at rust-lang/compiler-team#245. See the description there for background and rationale. The changes are pretty straightforward and should be easy to rebase if the proposal gets accepted at some point. r? @nikomatsakis cc @pnkfelix
Implement Hash for Infallible https://www.reddit.com/r/rust/comments/fmllgx/never_crate_stable_alternative_to/ lists not implementing `Hash` as a reason for the `never` crate. I see no reason not to implement `Hash` for `Infallible`, so might as well do it. No changes necessary for `!`, because `!` already implements `Hash` (see rust-lang#51404).
…fix, r=Amanieu Fix double-free and undefined behaviour in libstd::syn::unix::Thread::new While working on concurrency support for Miri, I found that the `libstd::syn::unix::Thread::new` method has two potential problems: double-free and undefined behaviour. **Double-free** could occur if the following events happened (credit for pointing this out goes to @RalfJung): 1. The call to `pthread_create` successfully launched a new thread that executed to completion and deallocated `p`. 2. The call to `pthread_attr_destroy` returned a non-zero value causing the `assert_eq!` to panic. 3. Since `mem::forget(p)` was not yet executed, the destructor of `p` would be executed and cause a double-free. As far as I understand, this code also violates the stacked-borrows aliasing rules and thus would result in **undefined behaviour** if these rules were adopted. The problem is that the ownership of `p` is passed to the newly created thread before the call to `mem::forget`. Since the call to `mem::forget` is still a call, it counts as a use of `p` and triggers UB. This pull request changes the code to use `mem::ManuallyDrop` instead of `mem::forget`. As a consequence, in case of a panic, `p` would be potentially leaked, which while undesirable is probably better than double-free or undefined behaviour.
|
@bors r+ p=3 rollup=never |
|
📌 Commit 1cdf210 has been approved by |
bors
added
the
S-waiting-on-bors
|
@bors p=4 |
|
⌛ Testing commit 1cdf210 with merge fcb9e03a725bbb8d4ed92bf4d1c8b6650f095e91... |
|
💔 Test failed - checks-azure |
bors
added
S-waiting-on-review
|
#70597 got r-. |
# for free
to join this conversation on GitHub.
Already have an account?
# 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:
-C codegen-unitsflag in incremental mode. #70156 (Make the rustc respect the-C codegen-unitsflag in incremental mode.)Failed merges:
STILL_FURTHER_SPECIALIZABLEflag #70658 (addSTILL_FURTHER_SPECIALIZABLEflag)r? @ghost