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 7 pull requests #128003

Closed
wants to merge 34 commits into from
Closed

Conversation

tgross35
Copy link
Contributor

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

momvart and others added 30 commits July 15, 2024 19:54
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.
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 rustbot added A-run-make Area: port run-make Makefiles to rmake.rs A-testsuite Area: The testsuite used to check the correctness of rustc O-solid Operating System: SOLID O-unix Operating system: Unix-like 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 Jul 20, 2024
@tgross35
Copy link
Contributor Author

@bors r+ rollup=never p=7

@bors
Copy link
Contributor

bors commented Jul 20, 2024

📌 Commit a8bded6 has been approved by tgross35

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 Jul 20, 2024
@tgross35 tgross35 closed this Jul 20, 2024
@tgross35 tgross35 deleted the rollup-p5h2m9a branch July 20, 2024 12:14
@tgross35
Copy link
Contributor Author

Didn't realize that Matthias beat me to it by a minute :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-run-make Area: port run-make Makefiles to rmake.rs A-testsuite Area: The testsuite used to check the correctness of rustc O-solid Operating System: SOLID 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-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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants