Skip to content

Rollup of 11 pull requests #140127

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

Merged
merged 35 commits into from
Apr 21, 2025
Merged

Rollup of 11 pull requests #140127

merged 35 commits into from
Apr 21, 2025

Conversation

ChrisDenton
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

thaliaarchi and others added 30 commits April 13, 2025 14:35
The only differences between these implementations are that Unix uses
relaxed ordering, but Hermit uses acquire/release, and Unix truncates
`argv` at the first null pointer, but Hermit doesn't. Since Hermit aims
for Unix compatibility, unify it with Unix.
Also update the symbol names as items have moved around a bit. The actual
name isn't that important, it just needs to be unique. But for debugging
it can be useful for it to point to the right place.
This is consistent with the style of `ByteString`.
- Reworked the test as a *centralized* version of checking that certain
  targets correctly require `-C target-cpu` being specified.
- Document test intention.
- Move `amdgpu-require-explicit-cpu.rs` under new dir
  `tests/ui/target-cpu/`
  - No other ui subdir really fits this "requires `-Ctarget-cpu`" check.
- `tests/ui/augmented-assignment-feature-gate-cross.rs`:
  - This was *originally* to feature-gate overloaded OpAssign
    cross-crate, but now let's keep it as a smoke test.
  - Renamed as `augmented-assignment-cross-crate.rs`.
  - Relocated under `tests/ui/binop/`.
-  `tests/ui/augmented-assignments.rs`:
  - Documented test intent.
  - Moved under `tests/ui/borrowck/`.
- `tests/ui/augmented-assignment-rpass.rs`:
  - Renamed to drop the `-rpass` suffix, since this was leftover from
    when `run-pass` test suite was a thing.
  - Moved under `tests/ui/binop/`.
- Reformat the test.
- Document test intention.
- Move test under `tests/ui/inference/`.
…rn-cleaning

error-pattern directive section cleaning
…ns, r=tgross35,Amanieu,traviscross

Stabilize `naked_functions`

tracking issue: rust-lang#90957
request for stabilization on tracking issue: rust-lang#90957 (comment)
reference PR: rust-lang/reference#1689

# Request for Stabilization

Two years later, we're ready to try this again. Even though this issue is already marked as having passed FCP, given the amount of time that has passed and the changes in implementation strategy, we should follow the process again.

## Summary

The `naked_functions` feature has two main parts: the `#[naked]` function attribute, and the `naked_asm!` macro.

An example of a naked function:

```rust
const THREE: usize = 3;

#[naked]
pub extern "sysv64" fn add_n(number: usize) -> usize {
    // SAFETY: the validity of the used registers
    // is guaranteed according to the "sysv64" ABI
    unsafe {
        core::arch::naked_asm!(
            "add rdi, {}",
            "mov rax, rdi",
            "ret",
            const THREE,
        )
    }
}
```

When the `#[naked]` attribute is applied to a function, the compiler won't emit a [function prologue](https://en.wikipedia.org/wiki/Function_prologue_and_epilogue) or epilogue when generating code for this function. This attribute is analogous to [`__attribute__((naked))`](https://developer.arm.com/documentation/100067/0608/Compiler-specific-Function--Variable--and-Type-Attributes/--attribute----naked---function-attribute) in C. The use of this feature allows the programmer to have precise control over the assembly that is generated for a given function.

The body of a naked function must consist of a single `naked_asm!` invocation, a heavily restricted variant of the `asm!` macro: the only legal operands are `const` and `sym`, and the only legal options are `raw` and `att_syntax`. In lieu of specifying operands, the `naked_asm!` within a naked function relies on the function's calling convention to determine the validity of registers.

## Documentation

The Rust Reference: rust-lang/reference#1689
(Previous PR: rust-lang/reference#1153)

## Tests

* [tests/run-make/naked-symbol-visiblity](https://github.com./rust-lang/rust/tree/master/tests/codegen/naked-fn) verifies that `pub`, `#[no_mangle]` and `#[linkage = "..."]` work correctly for naked functions
* [tests/codegen/naked-fn](https://github.com./rust-lang/rust/tree/master/tests/codegen/naked-fn) has tests for function alignment, use of generics, and validates the exact assembly output on linux, macos, windows and thumb
* [tests/ui/asm/naked-*](https://github.com./rust-lang/rust/tree/master/tests/ui/asm) tests for incompatible attributes, generating errors around incorrect use of `naked_asm!`, etc

## Interaction with other (unstable) features

### [fn_align](rust-lang#82232)

Combining `#[naked]` with `#[repr(align(N))]` works well, and is tested e.g. here

- https://github.com./rust-lang/rust/blob/master/tests/codegen/naked-fn/aligned.rs
- https://github.com./rust-lang/rust/blob/master/tests/codegen/naked-fn/min-function-alignment.rs

It's tested extensively because we do need to explicitly support the `repr(align)` attribute (and make sure we e.g. don't mistake powers of two for number of bytes).

## History

This feature was originally proposed in [RFC 1201](rust-lang/rfcs#1201), filed on 2015-07-10 and accepted on 2016-03-21. Support for this feature was added in [rust-lang#32410](rust-lang#32410), landing on 2016-03-23. Development languished for several years as it was realized that the semantics given in RFC 1201 were insufficiently specific. To address this, a minimal subset of naked functions was specified by [RFC 2972](rust-lang/rfcs#2972), filed on 2020-08-07 and accepted on 2021-11-16. Prior to the acceptance of RFC 2972, all of the stricter behavior specified by RFC 2972 was implemented as a series of warn-by-default lints that would trigger on existing uses of the `naked` attribute; these lints became hard errors in [rust-lang#93153](rust-lang#93153) on 2022-01-22. As a result, today RFC 2972 has completely superseded RFC 1201 in describing the semantics of the `naked` attribute.

More recently, the `naked_asm!` macro was added to replace the earlier use of a heavily restricted `asm!` invocation. The `naked_asm!` name is clearer in error messages, and provides a place for documenting the specific requirements of inline assembly in naked functions.

The implementation strategy was changed to emitting a global assembly block. In effect, an extern function

```rust
extern "C" fn foo() {
    core::arch::naked_asm!("ret")
}
```

is emitted as something similar to

```rust
core::arch::global_asm!(
    "foo:",
    "ret"
);

extern "C" {
    fn foo();
}
```

The codegen approach was chosen over the llvm naked function attribute because:

- the rust compiler can guarantee the behavior (no sneaky additional instructions, no inlining, etc.)
- behavior is the same on all backends (llvm, cranelift, gcc, etc)

Finally, there is now an allow list of compatible attributes on naked functions, so that e.g. `#[inline]` is rejected with an error. The `#[target_feature]` attribute on naked functions was later made separately unstable, because implementing it is complex and we did not want to block naked functions themselves on how target features work on them. See also rust-lang#138568.

relevant PRs for these recent changes

- rust-lang#127853
- rust-lang#128651
- rust-lang#128004
- rust-lang#138570
-
### Various historical notes

#### `noreturn`
[RFC 2972](https://github.com./rust-lang/rfcs/blob/master/text/2972-constrained-naked.md) mentions that naked functions

> must have a body which contains only a single asm!() statement which:
> iii. must contain the noreturn option.

Instead of `asm!`, the current implementation mandates that the body contain a single `naked_asm!` statement. The `naked_asm!` macro is a heavily restricted version of the `asm!` macro, making it easier to talk about and document the rules of assembly in naked functions and give dedicated error messages.

For `naked_asm!`, the behavior of the `asm!`'s `noreturn` option is implicit. The `noreturn` option means that it is UB for control flow to fall through the end of the assembly block. With `asm!`, this option is usually used for blocks that diverge (and thus have no return and can be typed as `!`). With `naked_asm!`, the intent is different: usually naked funtions do return, but they must do so from within the assembly block. The `noreturn` option was used so that the compiler would not itself also insert a `ret` instruction at the very end.

#### padding / `ud2`

A `naked_asm!` block that violates the safety assumption that control flow must not fall through the end of the assembly block is UB. Because no return instruction is emitted, whatever bytes follow the naked function will be executed, resulting in truly undefined behavior. There has been discussion whether rustc should emit an invalid instruction (e.g. `ud2`  on x86) after the `naked_asm!` block to at least fail early in the case of an invalid `naked_asm!`. It was however decided that it is more useful to guarantee that `#[naked]` functions NEVER contain any instructions besides those in the `naked_asm!` block.

# unresolved questions

None

r? ``@Amanieu``

I've validated the tests on x86_64 and aarch64
Hermit: Unify `std::env::args` with Unix

The only differences between these implementations of `std::env::args` are that Unix uses relaxed ordering, but Hermit uses acquire/release, and Unix truncates `argv` at the first null pointer, but Hermit doesn't. Since Hermit aims for Unix compatibility, unify it with Unix.

The atomic orderings were established in rust-lang#74006 (cc `@euclio)` for Unix and rust-lang#100579 (cc `@joboet)` for Hermit and, before those, they used mutexes and non-atomic statics. I think the difference in orderings is simply from them being changed at different times. The commented explanation for using acquire/release for Hermit is “to broadcast writes by the OS”. I'm not experienced enough with atomics to accurately judge, but I think acquire/release is stronger than needed. Either way, they should match.

Truncating at the first null pointer seems desirable, though I don't know whether it is necessary in practice on Hermit.

cc `@mkroening` `@stlankes` for Hermit
…r=joboet

Clarify why SGX code specifies linkage/symbol names for certain statics

Specifying linkage/symbol name is solely to ensure a single instance between the `std` crate and its unit tests.

Also update the symbol names as items have moved around a bit. The actual name isn't that important, it just needs to be unique. But for debugging it can be useful for it to point to the right place.
…errors

Advent of `tests/ui` (misc cleanups and improvements) [4/N]

Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang#133895.

### Review advice

- Best reviewed commit-by-commit.
- I can squash commits before merge, commits are separate to make it easier to review.
…ercote

Fix error when an intra doc link is trying to resolve an empty associated item

Fixes rust-lang#140026.

Assigning ```@nnethercote``` since they're the one who wrote the initial change.

I updated rustdoc code instead of compiler's because I think it makes more sense that the caller ensures on their side that the name they're looking for isn't empty.

r? ```@nnethercote```
@rustbot rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) A-run-make Area: port run-make Makefiles to rmake.rs A-rustc-dev-guide Area: rustc-dev-guide A-rustdoc-json Area: Rustdoc JSON backend O-SGX Target: SGX PG-exploit-mitigations Project group: Exploit mitigations S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. 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 Apr 21, 2025
@ChrisDenton
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Collaborator

bors commented Apr 21, 2025

📌 Commit 1cb9a0d has been approved by ChrisDenton

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 Apr 21, 2025
@bors
Copy link
Collaborator

bors commented Apr 21, 2025

⌛ Testing commit 1cb9a0d with merge d6c1e45...

@bors
Copy link
Collaborator

bors commented Apr 21, 2025

☀️ Test successful - checks-actions
Approved by: ChrisDenton
Pushing d6c1e45 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Apr 21, 2025
@bors bors merged commit d6c1e45 into rust-lang:master Apr 21, 2025
7 checks passed
@rustbot rustbot added this to the 1.88.0 milestone Apr 21, 2025
Copy link

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 8f2819b (parent) -> d6c1e45 (this PR)

Test differences

Show 102 test diffs

Stage 0

  • c_str2::formatted: pass -> [missing] (J3)
  • ffi::cstr::debug: [missing] -> pass (J3)

Stage 1

  • [ui] tests/rustdoc-ui/intra-doc/empty-associated-items.rs: [missing] -> pass (J0)
  • [ui] tests/ui/amdgpu-require-explicit-cpu.rs#cpu: ignore (ignored on targets without Rust's LLD) -> [missing] (J0)
  • [ui] tests/ui/amdgpu-require-explicit-cpu.rs#nocpu: ignore (ignored on targets without Rust's LLD) -> [missing] (J0)
  • [ui] tests/ui/augmented-assignments-feature-gate-cross.rs: pass -> [missing] (J0)
  • [ui] tests/ui/augmented-assignments-rpass.rs: pass -> [missing] (J0)
  • [ui] tests/ui/augmented-assignments.rs: pass -> [missing] (J0)
  • [ui] tests/ui/auto-instantiate.rs: pass -> [missing] (J0)
  • [ui] tests/ui/binop/augmented-assignment.rs: [missing] -> pass (J0)
  • [ui] tests/ui/binop/augmented-assignments-cross-crate.rs: [missing] -> pass (J0)
  • [ui] tests/ui/borrowck/augmented-assignments.rs: [missing] -> pass (J0)
  • [ui] tests/ui/feature-gates/feature-gate-naked_functions.rs: pass -> [missing] (J0)
  • [ui] tests/ui/inference/auto-instantiate.rs: [missing] -> pass (J0)
  • [ui] tests/ui/target-cpu/explicit-target-cpu.rs#amdgcn_cpu: [missing] -> pass (J0)
  • [ui] tests/ui/target-cpu/explicit-target-cpu.rs#amdgcn_nocpu: [missing] -> pass (J0)
  • [ui] tests/ui/target-cpu/explicit-target-cpu.rs#avr_cpu: [missing] -> pass (J0)
  • [ui] tests/ui/target-cpu/explicit-target-cpu.rs#avr_nocpu: [missing] -> pass (J0)
  • c_str2::formatted: pass -> [missing] (J2)
  • ffi::cstr::debug: [missing] -> pass (J2)

Stage 2

  • [ui] tests/ui/augmented-assignments-feature-gate-cross.rs: pass -> [missing] (J1)
  • [ui] tests/ui/augmented-assignments-rpass.rs: pass -> [missing] (J1)
  • [ui] tests/ui/augmented-assignments.rs: pass -> [missing] (J1)
  • [ui] tests/ui/auto-instantiate.rs: pass -> [missing] (J1)
  • [ui] tests/ui/binop/augmented-assignment.rs: [missing] -> pass (J1)
  • [ui] tests/ui/binop/augmented-assignments-cross-crate.rs: [missing] -> pass (J1)
  • [ui] tests/ui/borrowck/augmented-assignments.rs: [missing] -> pass (J1)
  • [ui] tests/ui/feature-gates/feature-gate-naked_functions.rs: pass -> [missing] (J1)
  • [ui] tests/ui/inference/auto-instantiate.rs: [missing] -> pass (J1)
  • [ui] tests/ui/target-cpu/explicit-target-cpu.rs#amdgcn_cpu: [missing] -> pass (J1)
  • [ui] tests/ui/target-cpu/explicit-target-cpu.rs#amdgcn_nocpu: [missing] -> pass (J1)
  • [ui] tests/ui/target-cpu/explicit-target-cpu.rs#avr_cpu: [missing] -> pass (J1)
  • [ui] tests/ui/target-cpu/explicit-target-cpu.rs#avr_nocpu: [missing] -> pass (J1)
  • [ui] tests/ui/amdgpu-require-explicit-cpu.rs#cpu: ignore (ignored on targets without Rust's LLD) -> [missing] (J4)
  • [ui] tests/ui/amdgpu-require-explicit-cpu.rs#nocpu: ignore (ignored on targets without Rust's LLD) -> [missing] (J4)
  • [ui] tests/ui/amdgpu-require-explicit-cpu.rs#cpu: pass -> [missing] (J5)
  • [ui] tests/ui/amdgpu-require-explicit-cpu.rs#nocpu: pass -> [missing] (J5)
  • [ui] tests/rustdoc-ui/intra-doc/empty-associated-items.rs: [missing] -> pass (J6)

Additionally, 64 doctest diffs were found. These are ignored, as they are noisy.

Job group index

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard d6c1e454aa8af5e7e59fbf5c4e7d3128d2f99582 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

  1. x86_64-apple-2: 4893.6s -> 8031.9s (64.1%)
  2. aarch64-apple: 3938.8s -> 4822.6s (22.4%)
  3. x86_64-gnu-llvm-20-1: 5287.9s -> 6328.4s (19.7%)
  4. dist-x86_64-apple: 9313.0s -> 10849.1s (16.5%)
  5. dist-apple-various: 7854.5s -> 6570.7s (-16.3%)
  6. x86_64-apple-1: 7989.6s -> 7008.7s (-12.3%)
  7. x86_64-msvc-2: 6873.8s -> 7263.4s (5.7%)
  8. dist-aarch64-apple: 4953.8s -> 4719.1s (-4.7%)
  9. x86_64-msvc-1: 8604.9s -> 9012.3s (4.7%)
  10. dist-various-2: 3407.0s -> 3257.2s (-4.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.

@ChrisDenton ChrisDenton deleted the rollup-2kye32h branch April 21, 2025 22:41
@rust-timer
Copy link
Collaborator

📌 Perf builds for each rolled up PR:

PR# Message Perf Build Sha
#134213 Stabilize naked_functions 4a827dba16e96b661701971196874429dd344f53 (link)
#139711 Hermit: Unify std::env::args with Unix 1f3579779801e09f645a7d2e1412cb189ba81007 (link)
#139795 Clarify why SGX code specifies linkage/symbol names for cer… 6483ed5b66e03ce92afe324c4a3e45b2e163eb3e (link)
#140036 Advent of tests/ui (misc cleanups and improvements) [4/N] f2aa44701218aa0d41978940486be7bf92ff28ee (link)
#140047 remove a couple clones d284bf1955f116cd1c15714f5afd3f71c9b8fe64 (link)
#140052 Fix error when an intra doc link is trying to resolve an em… a26a880230dbe5fbc7efd4a98aebf7668da687e1 (link)
#140074 rustdoc-json: Improve test for auto-trait impls 78631701cd66bab73baa461757c9b6df8804168f (link)
#140076 jsondocck: Require command is at start of line 1548c421e857cc447f5714c556f1f5d0356c0a3e (link)
#140107 rustc-dev-guide subtree update 3e1ea7aedbb55e27b34b6b7e43be2edb28b7fab2 (link)
#140111 cleanup redundant pattern instances 7e44ffe5c0c64135b9587a2070bb6ae916aee882 (link)
#140118 {B,C}Str: minor cleanup a62394adb541bb4aba776557f8489145cabefba0 (link)

previous master: 8f2819b0e3

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

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

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

Max RSS (memory usage)

Results (primary 0.2%, 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)
1.4% [0.4%, 5.0%] 9
Regressions ❌
(secondary)
1.7% [1.7%, 1.7%] 1
Improvements ✅
(primary)
-2.0% [-3.9%, -0.5%] 5
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.2% [-3.9%, 5.0%] 14

Cycles

Results (primary -0.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)
0.5% [0.5%, 0.5%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.5% [-0.5%, -0.5%] 1
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -0.0% [-0.5%, 0.5%] 2

Binary size

Results (primary 0.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)
0.1% [0.1%, 0.1%] 3
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.0% [-0.0%, -0.0%] 1
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.0% [-0.0%, 0.1%] 4

Bootstrap: 775.846s -> 774.01s (-0.24%)
Artifact size: 365.03 MiB -> 365.04 MiB (0.00%)

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

Rollup of 11 pull requests

Successful merges:

 - rust-lang#134213 (Stabilize `naked_functions`)
 - rust-lang#139711 (Hermit: Unify `std::env::args` with Unix)
 - rust-lang#139795 (Clarify why SGX code specifies linkage/symbol names for certain statics)
 - rust-lang#140036 (Advent of `tests/ui` (misc cleanups and improvements) [4/N])
 - rust-lang#140047 (remove a couple clones)
 - rust-lang#140052 (Fix error when an intra doc link is trying to resolve an empty associated item)
 - rust-lang#140074 (rustdoc-json: Improve test for auto-trait impls)
 - rust-lang#140076 (jsondocck: Require command is at start of line)
 - rust-lang#140107 (rustc-dev-guide subtree update)
 - rust-lang#140111 (cleanup redundant pattern instances)
 - rust-lang#140118 ({B,C}Str: minor cleanup)

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-attributes Area: Attributes (`#[…]`, `#![…]`) A-run-make Area: port run-make Makefiles to rmake.rs A-rustc-dev-guide Area: rustc-dev-guide A-rustdoc-json Area: Rustdoc JSON backend merged-by-bors This PR was explicitly merged by bors. O-SGX Target: SGX PG-exploit-mitigations Project group: Exploit mitigations 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-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.