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 5 pull requests #138208

Merged
merged 21 commits into from
Mar 8, 2025
Merged

Rollup of 5 pull requests #138208

merged 21 commits into from
Mar 8, 2025

Conversation

jhpratt
Copy link
Member

@jhpratt jhpratt commented Mar 8, 2025

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

lqd and others added 21 commits March 5, 2025 08:50
This will help stabilization of lld.
`-Zteach` is perma-unstable, barely used, the highlighting logic buggy and the flag being passed around is tech-debt. We should likely remove `-Zteach` in its entirely.
…al width

When encountering a single line span that is wider than the terminal, we keep context at the start and end of the span but otherwise remove the code from the middle. This is somewhat independent from whether the left and right margins of the output have been trimmed as well.

```
error[E0308]: mismatched types
  --> $DIR/long-span.rs:6:15
   |
LL | ... = [0, 0, 0, 0, ..., 0, 0];
   |       ^^^^^^^^^^^^^...^^^^^^^ expected `u8`, found `[{integer}; 1681]`
```

Address part of rust-lang#137680 (missing handling of the long suggestion). Fix rust-lang#125581.
Change the way that underline positions are calculated by delaying using
the "visual" column position until the last possible moment, instead
using the "file"/byte position in the file, and then calculating visual
positioning as late as possible. This should make the underlines more
resilient to non-1-width unicode chars.

Unfortunately, as part of this change (which fixes some visual bugs)
comes with the loss of some eager tab codepoint handling, but the output
remains legible despite some minor regression on the "margin trimming"
logic.
For the tests that make use of internal implementation details, we
include the module to test using #[path] in alloctests now.
…=cuviper

Put the alloc unit tests in a separate alloctests package

Same rationale as rust-lang#135937. This PR has some extra complexity though as a decent amount of tests are testing internal implementation details rather than the public api. As such I opted to include the modules containing the types under test using `#[path]` into the alloctests package. This means that those modules still need `#[cfg(test)]`, but the rest of liballoc no longer need it.
Windows: Fix error in `fs::rename` on Windows 1607

Fixes rust-lang#137499

There's a bug in our Windows implementation of `fs::rename` that only manifests on a specific version of Windows. Both newer and older versions of Windows work.

I took the safest route to fixing this by using the old `MoveFileExW` function to implement this and only falling back to the new behaviour if that fails. This is similar to what is done in `unlink` (just above this function).

try-job: dist-x86_64-mingw
try-job: dist-x86_64-msvc
self-contained linker: conservatively default to `-znostart-stop-gc` on x64 linux

To help stabilization, this PR disables an LLD optimization on  x64 linux 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````
On long spans, trim the middle of them to make them fit in the terminal width

When encountering a single line span that is wider than the terminal, we keep context at the start and end of the span but otherwise remove the code from the middle. This is somewhat independent from whether the left and right margins of the output have been trimmed as well.

```
error[E0308]: mismatched types
  --> $DIR/long-span.rs:6:15
   |
LL | ... = [0, 0, 0, 0, ..., 0, 0];
   |       ^^^^^^^^^^^^^...^^^^^^^ expected `u8`, found `[{integer}; 1681]`
```

Address part of rust-lang#137680 (missing handling of the long suggestion). Fix rust-lang#125581.

---

Change the way that underline positions are calculated by delaying using the "visual" column position until the last possible moment, instead using the "file"/byte position in the file, and then calculating visual positioning as late as possible. This should make the underlines more resilient to non-1-width unicode chars.

Unfortunately, as part of this change (which fixes some visual bugs) comes with the loss of some eager tab codepoint handling, but the output remains legible despite some minor regression on the "margin trimming" logic.

---

`-Zteach` is perma-unstable, barely used, the highlighting logic buggy and the flag being passed around is tech-debt. We should likely remove `-Zteach` in its entirely.
…lett

Mention `env` and `option_env` macros in `std::env::var` docs

Fixes rust-lang#138159.

Just like there are mentions in `env!` and `option_env!` docs to `std::env::var`, it'd be nice to have a "mention back" as well.
@rustbot rustbot added A-testsuite Area: The testsuite used to check the correctness of rustc A-tidy Area: The tidy tool O-windows Operating system: Windows 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. rollup A PR which is a rollup labels Mar 8, 2025
@jhpratt
Copy link
Member Author

jhpratt commented Mar 8, 2025

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Mar 8, 2025

📌 Commit 6576d35 has been approved by jhpratt

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 8, 2025
@jieyouxu
Copy link
Member

jieyouxu commented Mar 8, 2025

(going to schedule the beta backport first, we may want to let some rollup=nevers have a chance now that the queue isn't so busy)

@bors
Copy link
Contributor

bors commented Mar 8, 2025

⌛ Testing commit 6576d35 with merge 79b43dfde9dd1e3bed3c6ef7e9cfc708422f671f...

@bors
Copy link
Contributor

bors commented Mar 8, 2025

☀️ Test successful - checks-actions
Approved by: jhpratt
Pushing 79b43df to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Mar 8, 2025
@bors bors merged commit 79b43df into rust-lang:master Mar 8, 2025
7 checks passed
@rustbot rustbot added this to the 1.87.0 milestone Mar 8, 2025
@rust-log-analyzer
Copy link
Collaborator

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

gh pr comment ${HEAD_PR} -F output.log
shell: /usr/bin/bash -e {0}
##[endgroup]
fatal: ambiguous argument 'HEAD^1': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
##[error]Process completed with exit code 128.

@rust-timer
Copy link
Collaborator

📌 Perf builds for each rolled up PR:

PR# Message Perf Build Sha
#136642 Put the alloc unit tests in a separate alloctests package 7befc2425f759f8cf964fab3dd9de210daf0ff7b (link)
#137528 Windows: Fix error in fs::rename on Windows 1607 4911ab1858c57c53f5f47119ed4fc762221a4642 (link)
#137685 self-contained linker: conservatively default to `-znostart… 9441e06889db1f402e3e1c857d0de69a9a3adb2e (link)
#137757 On long spans, trim the middle of them to make them fit in … 4aec92c66db95d7dba15839429e20b54c4f97848 (link)
#138189 Mention env and option_env macros in std::env::var do… d754a6e18cbc2def7f31f5e1d925ab6344939f44 (link)

previous master: cdd8af2299

In the case of a perf regression, run the following command for each PR you suspect might be the cause: @rust-timer build $SHA

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (79b43df): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-0.2% [-0.2%, -0.2%] 1
All ❌✅ (primary) - - 0

Max RSS (memory usage)

Results (primary -3.0%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
2.3% [2.3%, 2.3%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-4.3% [-7.9%, -1.5%] 4
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -3.0% [-7.9%, 2.3%] 5

Cycles

Results (primary -1.5%, secondary -1.7%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-1.5% [-1.9%, -1.2%] 2
Improvements ✅
(secondary)
-1.7% [-1.7%, -1.7%] 1
All ❌✅ (primary) -1.5% [-1.9%, -1.2%] 2

Binary size

Results (primary -0.0%, secondary -0.1%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
0.1% [0.0%, 0.4%] 18
Regressions ❌
(secondary)
0.0% [0.0%, 0.2%] 13
Improvements ✅
(primary)
-0.1% [-0.2%, -0.0%] 28
Improvements ✅
(secondary)
-0.8% [-0.8%, -0.8%] 3
All ❌✅ (primary) -0.0% [-0.2%, 0.4%] 46

Bootstrap: 766.8s -> 766.2s (-0.08%)
Artifact size: 362.14 MiB -> 362.14 MiB (0.00%)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-testsuite Area: The testsuite used to check the correctness of rustc A-tidy Area: The tidy tool merged-by-bors This PR was explicitly merged by bors. O-windows Operating system: Windows 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. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.