Skip to content

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

RalfJung and others added 14 commits March 3, 2025 10:53
`uclibc` is not an environment understood by LLVM, it is only a concept
in Clang that can be selected with `-muclibc` (it affects which dynamic
linker is passed to the static linker's `-dynamic-linker` flag).

In fact, using `uclibcgnueabi`/`uclibc` is actively harmful, as it
prevents LLVM from seeing that the target is gnu-like; we should use
`gnueabi`/`gnu` directly instead.
By marking `__errno_location` as `#[ffi_const]` and `std::sys::os::errno` as `#[inline]`, this PR allows merging multiple calls to `io::Error::last_os_error()` into one.
stabilize const_cell

``@rust-lang/libs-api`` ``@rust-lang/wg-const-eval`` I see no reason to wait any longer, so I propose we stabilize the use of `Cell` in `const fn`  -- specifically the APIs listed here:
```rust
// core::cell

impl<T> Cell<T> {
    pub const fn replace(&self, val: T) -> T;
}

impl<T: Copy> Cell<T> {
    pub const fn get(&self) -> T;
}

impl<T: ?Sized> Cell<T> {
    pub const fn get_mut(&mut self) -> &mut T;
    pub const fn from_mut(t: &mut T) -> &Cell<T>;
}

impl<T> Cell<[T]> {
    pub const fn as_slice_of_cells(&self) -> &[Cell<T>];
}
```
Unfortunately, `set` cannot be made `const fn` yet as it drops the old contents.

Fixes rust-lang#131283
…ouxu

Fix `uclibc` LLVM target triples

`uclibc` is not an environment understood by LLVM, it is only a concept in Clang that can be selected with `-muclibc` (it affects which dynamic linker is passed to the static linker's `-dynamic-linker` flag).

In fact, using `uclibcgnueabi`/`uclibc` is actively harmful, as it prevents LLVM from seeing that the target is gnu-like; we should use `gnueabi`/`gnu` directly instead.

Motivation: To make it easier to verify that [`cc-rs`' conversion from `rustc` to Clang/LLVM triples](rust-lang/cc-rs#1431) is correct.

**There are no target maintainers for these targets.** So I'll CC ``@lancethepants`` and ``@skrap`` who maintain the related `armv7-unknown-linux-uclibceabi` and `armv7-unknown-linux-uclibceabihf` (both of which already pass `-gnu` instead of `-uclibc`) in case they have any insights.

r? jieyouxu
…boet

Start using `with_native_path` in `std::sys::fs`

Ideally, each platform should use their own native path type internally. This will, for example, allow passing a `CStr` directly to `std::fs::File::open` and therefore avoid the need for allocating a new null-terminated C string.

However, doing that for every function and platform all at once makes for a large PR that is way too prone to breaking. So this PR does some minimal refactoring which should help progress towards that goal. The changes are Unix-only and even then I avoided functions that require more changes so that this PR is just moving things around.

r? joboet
std: deduplicate `errno` accesses

By marking `__errno_location` as `#[ffi_const]` and `std::sys::os::errno` as `#[inline]`, this PR allows merging multiple calls to `io::Error::last_os_error()` into one.
compiletest: Support matching diagnostics on lines below

Using `//~vvv ERROR`.

This is not needed often, but it's easy to support, and it allows to eliminate a class of `error-pattern`s that cannot be eliminated in any other way.

See the diff for the examples of such patterns coming from parser.
Some of them can be matched by `//~ ERROR` or `//~^ ERROR` as well (when the final newline is allowed), but it changes the shape of reported spans, so I chose to keep the spans by using `//~v ERROR`.
…mpiler-errors

`BackendRepr::is_signed`: comment why this may panics

Was wondering why this method could panics while the others couldn't, so quote PR rust-lang#70189.
…-errors

Mark .pp files as Rust

Pretty-printing tests generate `.pp` files, but GitHub classify and highlight them as Pascal:
[https://github.com/search?q=repo:rust-lang/rust+path:*.pp&type=code](https://github.com/search?q=repo%3Arust-lang%2Frust+path%3A*.pp&type=code)

``@rustbot`` label +A-meta +A-testsuite
@rustbot rustbot added A-compiletest Area: The compiletest test runner A-rustc-dev-guide Area: rustc-dev-guide A-testsuite Area: The testsuite used to check the correctness of rustc 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 Mar 29, 2025
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Collaborator

bors commented Mar 29, 2025

📌 Commit ed1f776 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 29, 2025
@bors
Copy link
Collaborator

bors commented Mar 29, 2025

⌛ Testing commit ed1f776 with merge 2196aff...

@bors
Copy link
Collaborator

bors commented Mar 30, 2025

☀️ Test successful - checks-actions
Approved by: matthiaskrgr
Pushing 2196aff to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Mar 30, 2025
@bors bors merged commit 2196aff into rust-lang:master Mar 30, 2025
7 checks passed
@rustbot rustbot added this to the 1.88.0 milestone Mar 30, 2025
Copy link
Contributor

What is this? This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 1799887 (parent) -> 2196aff (this PR)

Test differences

No test diffs found

Job duration changes

  1. aarch64-gnu: 6461.0s -> 9888.2s (53.0%)
  2. aarch64-gnu-debug: 3991.9s -> 5928.0s (48.5%)
  3. x86_64-apple-2: 5236.7s -> 6337.5s (21.0%)
  4. dist-x86_64-msvc-alt: 7404.9s -> 8245.5s (11.4%)
  5. i686-mingw-3: 7898.8s -> 8258.8s (4.6%)
  6. dist-x86_64-freebsd: 4751.4s -> 4952.5s (4.2%)
  7. x86_64-gnu-distcheck: 4672.7s -> 4822.2s (3.2%)
  8. dist-loongarch64-linux: 6159.6s -> 6338.5s (2.9%)
  9. x86_64-msvc-1: 8451.7s -> 8688.9s (2.8%)
  10. x86_64-gnu: 6319.3s -> 6468.9s (2.4%)
How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

@rust-timer
Copy link
Collaborator

📌 Perf builds for each rolled up PR:

PR# Message Perf Build Sha
#137928 stabilize const_cell 190a081e02a3940b5ca8a46edb9ab55f621cd30f (link)
#138431 Fix uclibc LLVM target triples e6e42837e3933218938d3a557e8ac060e1cedd3f (link)
#138832 Start using with_native_path in std::sys::fs 4cdaf092bfc5f63e1e9b01ebc6ca8788f4c8c646 (link)
#139081 std: deduplicate errno accesses 82f8d935d50c9eb254af8d0e68c5234d497f273d (link)
#139100 compiletest: Support matching diagnostics on lines below ff5a54d42b35fe9e76f116d500e3d0dfabdead01 (link)
#139105 BackendRepr::is_signed: comment why this may panics b8c0247c9f3bac1bda5df7cce9aac30826f81e4e (link)
#139106 Mark .pp files as Rust e570844db508b06cc23266bc598733c476fde6c1 (link)

previous master: 1799887bb2

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 (2196aff): comparison URL.

Overall result: ❌ regressions - 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.3% [0.3%, 0.3%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.3% [0.3%, 0.3%] 1

Max RSS (memory usage)

Results (secondary -2.4%)

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)
- - 0
Improvements ✅
(secondary)
-2.4% [-2.4%, -2.4%] 1
All ❌✅ (primary) - - 0

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

Results (primary 0.0%, secondary 0.2%)

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.2%] 13
Regressions ❌
(secondary)
0.2% [0.1%, 0.2%] 38
Improvements ✅
(primary)
-0.1% [-0.1%, -0.1%] 3
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.0% [-0.1%, 0.2%] 16

Bootstrap: 777.64s -> 777.614s (-0.00%)
Artifact size: 365.94 MiB -> 365.95 MiB (0.00%)

github-actions bot pushed a commit to model-checking/verify-rust-std that referenced this pull request Apr 2, 2025
…iaskrgr

Rollup of 7 pull requests

Successful merges:

 - rust-lang#137928 (stabilize const_cell)
 - rust-lang#138431 (Fix `uclibc` LLVM target triples)
 - rust-lang#138832 (Start using `with_native_path` in `std::sys::fs`)
 - rust-lang#139081 (std: deduplicate `errno` accesses)
 - rust-lang#139100 (compiletest: Support matching diagnostics on lines below)
 - rust-lang#139105 (`BackendRepr::is_signed`: comment why this may panics)
 - rust-lang#139106 (Mark .pp files as Rust)

r? `@ghost`
`@rustbot` modify labels: rollup
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-compiletest Area: The compiletest test runner A-rustc-dev-guide Area: rustc-dev-guide A-testsuite Area: The testsuite used to check the correctness of rustc merged-by-bors This PR was explicitly merged by bors. 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.

10 participants