Rollup of 8 pull requests #128000
Closed
Rollup of 8 pull requests #128000
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
Signed-off-by: onur-ozkan <[email protected]>
sometimes a safety comment is a prayer. avoid fuzzy provenance casts after deref. Co-authored-by: Jonas Böttiger <[email protected]>
This is technically "not necessary", as we will "just" segfault instead if we e.g. arrive inside the handler fn with the null altstack. However, it seems incorrect to go about this hoping that segfaulting is okay, seeing as how our purpose here is to mitigate stack overflow problems. Make sure NEED_ALTSTACK syncs with PAGE_SIZE when we do. Co-authored-by: Jonas Böttiger <[email protected]>
Editorialize on the wisdom of this as we do.
Note that current_guard is probably not unsafe for future work.
Co-authored-by: Jonas Böttiger <[email protected]>
Now there are separate functions for running a command without capturing, running while capturing stdout and running while capturing everything. This should help avoid situations where stdout/stderr is accessed when it was not captured.
…ut/stderr If e.g. only stdout is captured, but the caller tries to read stderr, previously they would get back an empty string. Now the code will explicitly panic when accessing an uncaptured output stream.
Only the last candidate can possibly have more match pairs, so this can be separate from the main or-candidate postprocessing loop.
When CI rustc is enabled and rustdoc sources are unchanged, we can use the precompiled rustdoc from the CI rustc's sysroot. This speeds up bootstrapping quite a lot by avoiding unnecessary rustdoc compilation. Signed-off-by: onur-ozkan <[email protected]>
…Kobzol use precompiled rustdoc with CI rustc When CI rustc is enabled and rustdoc sources are unchanged, we can use the precompiled rustdoc from the CI rustc's sysroot. This speeds up bootstrapping quite a lot by avoiding unnecessary rustdoc compilation.
Migrate 9 more very similar FFI `run-make` tests to rmake Part of rust-lang#121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html). For the tracking issue: - return-non-c-like-enum-from-c - pass-non-c-like-enum-to-c - c-static-dylib - c-static-rlib - extern-fn-generic - extern-fn-with-union - lto-no-link-whole-rlib - linkage-attr-on-static - issue-28595
…illot Add a hook for `should_codegen_locally` This PR lifts the module-local function `should_codegen_locally` to `TyCtxt` as a hook. In addition to monomorphization, this function is used for checking the dependency of `compiler_builtins` on other libraries. Moving this function to the hooks also makes overriding it possible for the tools that use the rustc interface.
…=onur-ozkan Bootstrap command refactoring: make command output API more bulletproof (step 7) Continuation of rust-lang#127680. This PR modifies the API of running commands to make it more explicit when a command is expected to produce programmatically handled output. Now if you call just `run`, you cannot access the stdout/stderr by accident, because it will not be returned to the caller. This API change might be seen as overkill, let me know what do you think. In any case, I'd like to land the second commit, to make it harder to accidentally read stdout/stderr of commands that did not capture output (now you'd get an empty string as a result, but you should probably get a panic instead, if you try to read uncaptured stdout/stderr). Tracking issue: rust-lang#126819 r? `@onur-ozkan`
…ack-overflow-fn, r=joboet
unix: document unsafety for std `sig{action,altstack}`
I found many surprising elements here while trying to wrap a measly 5 functions with `unsafe`. I would rather not "just" mindlessly wrap this code with `unsafe { }`, so I decided to document it properly.
On Unix, this code covers the "create and setup signal handler" part of the stack overflow code, and serves as the primary safety boundary for the signal handler. It is rarely audited, very gnarly, and worth extra attention. It calls other unsafe functions defined in this module, but "can we correctly map the right memory, or find the right address ranges?" are separate questions, and get increasingly platform-specific. The question here is the more general "are we doing everything in the correct order, and setting up the handler in the correct way?"
As part of this audit, I noticed that we do some peculiar things that we should probably refrain from. However, I avoided making changes that I deemed might have a different final result in Rust programs. I did, however, reorder some events so that the signal handler is installed _after_ we install the alternate stack. We do not run much code between these events, but it is probably best if the timespan between the handler being available and the new stack being installed is 0 nanoseconds.
…or-kmc-solid, r=Amanieu kmc-solid: `#![forbid(unsafe_op_in_unsafe_fn)]` The path logic _should_ handle the forbiddance in the itron sources correctly, despite them being an "out-of-line" module.
match lowering: Split `finalize_or_candidate` into more coherent methods I noticed that `finalize_or_candidate` was responsible for several different postprocessing tasks, making it difficult to understand. This PR aims to clean up some of the confusion by: - Extracting `remove_never_subcandidates` from `merge_trivial_subcandidates` - Extracting `test_remaining_match_pairs_after_or` from `finalize_or_candidate` - Taking what remains of `finalize_or_candidate`, and inlining it into its caller --- Reviewing individual commits and ignoring whitespace is recommended. Most of the large-looking changes are just moving existing code around, mostly unaltered. r? `@Nadrieril`
…thercote run_make_support: skip rustfmt for lib.rs To avoid them getting reordered once rust-lang#125443 goes through. r? `@nnethercote` (since you were working on this)
rustbot
added
A-run-make
|
@bors r+ rollup=never p=8 |
bors
added
S-waiting-on-bors
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
Let's land #127463 first. |
|
|
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:
run-maketests to rmake #127663 (Migrate 9 more very similar FFIrun-maketests to rmake)should_codegen_locally#127779 (Add a hook forshould_codegen_locally)sig{action,altstack}#127843 (unix: document unsafety for stdsig{action,altstack})#![forbid(unsafe_op_in_unsafe_fn)]#127873 (kmc-solid:#![forbid(unsafe_op_in_unsafe_fn)])finalize_or_candidateinto more coherent methods #127917 (match lowering: Splitfinalize_or_candidateinto more coherent methods)Failed merges:
issue-14698.issue-33329andissue-107094run-maketests to rmake or ui #127820 (Rewrite and renameissue-14698.issue-33329andissue-107094run-maketests to rmake or ui)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup