Reorganize the `run-make-support` library
The `run_make_support` library has a kitchen sink `lib.rs` that make discovery/learning very difficult. Let's try to improve that by breaking up `lib.rs` into smaller more organized modules. This is a precursor to improving the documentation and learnability of the `run_make_support` library.
### Changes
- Breakup `lib.rs` into smaller modules according to functionality
- Rename `recursive_diff` -> `assert_dirs_are_equal`
- Rename one of the `read_dir` with callback interface as `read_dir_entries`
- Coalesced fs-related stuff onto a `fs` module, re-exported to tests as `rfs`
- Minor doc improvements / fixes in a few places (I have a follow-up documentation PR planned)
This PR is best reviewed commit-by-commit.
r? `@Kobzol` (or Mark, or T-compiler or T-bootstrap)
try-job: x86_64-msvc
try-job: aarch64-apple
try-job: test-various
try-job: armhf-gnu
try-job: dist-x86_64-linux
There were *two* `read_dir` helpers, one being a simple
`std::fs::read_dir` wrapper, the other has a different callback-based
signature. We also rename the callback-based `read_dir` as
`read_dir_entries`.
Also don't top-level re-export most `fs::*` helpers.
maintain the given order on step execution
Previously step execution disregarded the CLI order and this change executes the given steps in the order specified on CLI.
For example, running `x $kind a b c` will execute `$kind` step for `a`, then `b`, then `c` crates in the specified order.
Fixes#126165
cc `@matthiaskrgr`
Previously step execution disregarded the CLI order and this change executes the given
steps in the order specified on CLI.
For example, running `x $kind a b c` will execute `$kind` step for `a`, then `b`, then `c` crates
in the specified order.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
bootstrap: open `llvm-config` as r+w
This previously failed on Windows and prevented building on Windows for compiler stuff because the `llvm-config` file was open as read-only.
Tested locally on a Windows machine.
Fixes#127849.
Prevent double reference in generic futex
In the Windows futex implementation we were a little lax at allowing references to references (i.e. `&&`) which can lead to deadlocks due to reading the wrong memory address. This uses a trait to tighten the constraints and ensure this doesn't happen.
r? libs
Make more Windows functions `#![deny(unsafe_op_in_unsafe_fn)]`
As part of #127747, I've evaluated some more Windows functions and added `unsafe` blocks where necessary. Some are just trivial wrappers that "inherit" the full unsafety of their function, but for others I've added some safety comments. A few functions weren't actually unsafe at all. I think they were just using `unsafe fn` to avoid an `unsafe {}` block.
I'm not touching `c.rs` yet because that is partially being addressed by another PR and also I have plans to further reduce the number of wrapper functions we have in there.
r? libs
Rollup of 9 pull requests
Successful merges:
- #125206 (Simplify environment variable examples)
- #126271 (Skip fast path for dec2flt when optimize_for_size)
- #126776 (Clean up more comments near use declarations)
- #127444 (`impl Send + Sync` and override `count` for the `CStr::bytes` iterator)
- #127512 (Terminate `--print link-args` output with newline)
- #127792 (std: Use `read_unaligned` for reads from DWARF)
- #127807 (Use futex.rs for Windows thread parking)
- #127833 (zkvm: add `#[forbid(unsafe_op_in_unsafe_fn)]` in `stdlib`)
- #127836 (std: Forbid unwrapped unsafe ops in xous and uefi modules)
Failed merges:
- #127813 (Prevent double reference in generic futex)
r? `@ghost`
`@rustbot` modify labels: rollup
