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 10 pull requests #137877

Closed
wants to merge 24 commits into from

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

jyn514 and others added 24 commits February 13, 2025 10:24
`py` is not installed by default *and* trying to run it results in a
popup asking if you want to install it. `python3` is installed by
default.

This hopefully should not be too disruptive to people on Windows, since
they should be going through `x.ps1` instead anyway. Just in case, I've
added a check for Cygwin and Msys (i'm not sure how else you'd get a
bash shell on windows).
To make the error cases easier to spot on a quick glance.
with where to *actually* look for more details
Currently, test case generators are launched in parallel and their test
cases also run in parallel, all within the same pool. I originally
implemented this with the assumption that there would be an advantage in
parallelizing the generators themselves, but this turns out to not
really have any benefit.

Simplify things by running generators in series while keeping their test
cases parallelized. This makes the code easier to follow, and there is
no longer a need for MPSC or multiprogress bars. Additionally, the UI
output can be made cleaner.
This will help stabilization of lld.
That unstable feature completed fcp-close, so the compiler needs to be
migrated away to allow its removal. In this case, `cg_llvm` and `cg_gcc`
were using raw entries to optimize their `const_str_cache` lookup and
insertion. We can change that to separate `get` and (on miss) `insert`
calls, so we still have the fast path avoiding string allocation when
the cache hits.
…heck, r=Mark-Simulacrum

Remove `:` from `stack-protector-heuristics-effect.rs` Filecheck Pattern

With function sections, the assembly label does not necessarily end in `:`.

Remove trailing `:` to be more consistent with the rest of the existing Filecheck patterns.
```
// CHECK-LABEL: local_string_addr_taken
#[no_mangle]
pub fn local_string_addr_taken(f: fn(&String)) {
    let x = String::new();
    f(&x);
```
Look for `python3` first on MacOS, not `py`

`py` is not installed by default *and* trying to run it results in a popup asking if you want to install it. `python3` is installed by default.

This hopefully should not be too disruptive to people on Windows, since they should be going through `x.ps1` instead anyway. Just in case, I've added a check for Cygwin and Msys (i'm not sure how else you'd get a bash shell on windows).

I've tested this on macOS, WSL, "git bash" (which appears to be MSYS), and MSVC with `bash -c ./x` (which runs in WSL, but differently than interactive bash 🙃). I haven't tested Cygwin, which is unsupported anyway, but the code tries to make it work.
…ude-in-config.toml, r=onur-ozkan

Add exclude to config.toml

Closes: rust-lang#35678

r? ``@onur-ozkan``
…mulacrum

Slightly reformat `std::fs::remove_dir_all` error docs

To make the error cases easier to spot on a quick glance, as I've been bitten by this a couple of times already 💀

cc rust-lang#137230.
Undeprecate env::home_dir

rust-lang#132515 fixed the implementation of `env::home_dir`, but didn't remove the deprecation.

Based on [this comment](rust-lang#132515 (comment)), libs-api decided to undeprecate in the next release. Let's do that!

cc rust-lang#132650
…, r=Mark-Simulacrum

Minor internal comments fix for `BufRead::read_line`

Just a little fix that came up while I was reading through this source code, and had to search for a few minutes to find out what was actually *meant* here.
…allelization, r=Mark-Simulacrum

Simplify parallelization in test-float-parse

Currently, test case generators are launched in parallel and their test cases also run in parallel, all within the same pool. I originally implemented this with the assumption that there would be an advantage in parallelizing the generators themselves, but this turns out to not really have any benefit.

Simplify things by running generators in series while keeping their test cases parallelized. This makes the code easier to follow, and there is no longer a need for MPSC or multiprogress bars. Additionally, the UI output can be made cleaner.
self-contained linker: conservatively default to `-znostart-stop-gc`

To help stabilization, this PR disables an LLD optimization with respect to `--gc-sections` and encapsulation symbols: it will reduce the number of crates needing to opt-out of lld due to this bfd / lld difference. For example, all the people using [linkme](https://github.com/dtolnay/linkme), which [doesn't work with lld](dtolnay/linkme#63) or on nightly, need to disable lld.

More information about all this, and the historical differences, can be found in:
- https://maskray.me/blog/2021-01-31-metadata-sections-comdat-and-shf-link-order
- https://lld.llvm.org/ELF/start-stop-gc

This optimization has [no visible impact](rust-lang#137685 (comment)) on our benchmarks, so we can use it by default and have a safer/more conservative starting point to remove friction during migration. We can them emit an FCW for the cases where lld detects reliance on encapsulation symbols without `-znostart-stop-gc`, and then revert back to lld's default after a while. No one compiling on nightly relies on this difference, obviously, so doing an FCW is not necessary until after lld is used on stable.

I've tested that this correctly links on `linkme` examples. I've also quickly tried to crate an rmake test but the setup with encapsulation symbols is annoying to reproduce: a few link section/name attributes is not enough, we also need to collect symbols between the encapsulation symbols, without referencing them in code, for `-znostart-stop-gc` to only impact this... It should of course be doable though, maybe `@Kobzol` will look into it if they have time.

r? `@petrochenkov`
… r=notriddle

`librustdoc`: 2024 edition! 🎊

Like rust-lang#137333 , but for rustdoc 😁
…k-Simulacrum

Stop using `hash_raw_entry` in `CodegenCx::const_str`

That unstable feature (rust-lang#56167) completed fcp-close, so the compiler needs to be
migrated away to allow its removal. In this case, `cg_llvm` and `cg_gcc`
were using raw entries to optimize their `const_str_cache` lookup and
insertion. We can change that to separate `get` and (on miss) `insert`
calls, so we still have the fast path avoiding string allocation when
the cache hits.
@rustbot rustbot added 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. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output. labels Mar 2, 2025
@rustbot rustbot added the rollup A PR which is a rollup label Mar 2, 2025
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=3

@bors
Copy link
Collaborator

bors commented Mar 2, 2025

📌 Commit 9cade29 has been approved by matthiaskrgr

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 Mar 2, 2025
@tgross35
Copy link
Contributor

tgross35 commented Mar 2, 2025

@bors r-

Sorry, I added a small change to #137525 since there are a few jobs in front of this. I'll recreate the rollup.

Done: #137879

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 2, 2025
@tgross35 tgross35 closed this Mar 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. 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. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output.
Projects
None yet
Development

Successfully merging this pull request may close these issues.