Skip to content

Rollup of 5 pull requests#156553

Closed
JonathanBrouwer wants to merge 21 commits into
rust-lang:mainfrom
JonathanBrouwer:rollup-c1pG1UW
Closed

Rollup of 5 pull requests#156553
JonathanBrouwer wants to merge 21 commits into
rust-lang:mainfrom
JonathanBrouwer:rollup-c1pG1UW

Conversation

@JonathanBrouwer

Copy link
Copy Markdown
Contributor

Successful merges:

r? @ghost

Create a similar rollup

Urgau and others added 21 commits May 9, 2026 12:23
…e it always is

`rustc_resolve` doesn't resolve type-relative paths since that's the job
of HIR ty lowering and HIR typeck. `segment.res` comes from
`rustc_resolve` and is thus always `Res::Err`.
So just try to obtain the `TypeckResults` immediately since they contain
the actual resolution as deduced by HIR typeck.
Don't unnecessarily try to obtain the type-dependent definition of callees
in `visit_expr`, just let `visit_qpath` handle callees.
This means that for callees that are

* `Resolved` paths (the majority of callees) we don't try to `typeck` the
  enclosing body which should improve perf if the body doesn't contain
  any type-dependent definitions.
* actually `TypeRelative` paths we don't resolve them twice (with
  slightly different spans)
This function wraps POSIX `killpg()`, and on Linux additionally
may be implemented by `pidfd_send_signal`.
This function wraps POSIX `killpg(pid, SIGKILL)`, and on Linux
additionally may be implemented by `pidfd_send_signal`.
Add lint againts invalid runtime symbol definitions

This PR adds a deny-by-default lint againts invalid runtime symbol definitions, those runtime symbols are assumed and used by `core`[^1] and `rustc` with a specific definition.

We have had multiple reports of users tripping over `std` symbols (addressed in a future PR):
 - [Why does `#[no_mangle] fn open() {}` make `cargo t` hang?](https://users.rust-lang.org/t/why-does-no-mangle-fn-open-make-cargo-t-hang/103423)
 - [Pointer becomes misaligned in test with `no_mangle`](https://users.rust-lang.org/t/pointer-becomes-misaligned-in-test-with-no-mangle/126580)

This PR is a second attempt after rust-lang#146505, where T-lang had [some reservations](rust-lang#146505 (comment)) about a blanket lint that does not check the signature, which is now done with this PR, and about linting of `std` runtime symbols when std is not linked, which this PR omits by not including any std runtime symbols (for now).

## `invalid_runtime_symbol_definitions`

*(deny-by-default)*

The `invalid_runtime_symbol_definitions` lint checks the signature of items whose symbol name is a runtime symbols expected by `core`.

### Example

```rust,compile_fail
#[unsafe(no_mangle)]
pub fn memcmp() {} // invalid definition of the `memcmp` runtime symbol
```

```text
error: invalid definition of the runtime `memcmp` symbol used by the standard library
 --> a.rs:2:1
  |
4 | fn memcmp() {}
  | ^^^^^^^^^^^
  |
  = note: expected `unsafe extern "C" fn(*const c_void, *const c_void, usize) -> i32`
          found    `fn()`
  = help: either fix the signature or remove any attributes like `#[unsafe(no_mangle)]`, `#[unsafe(export_name = "memcmp")]`, or `#[link_name = "memcmp"]`
  = note: `#[deny(invalid_runtime_symbol_definitions)]` on by default
```

### Explanation

Up-most care is required when defining runtime symbols assumed and used by the standard library. They must follow the C specification, not use any standard-library facility or undefined behavior may occur.

The symbols currently checked are `memcpy`, `memmove`, `memset`, `memcmp`, `bcmp` and `strlen`.

[^1]: https://doc.rust-lang.org/core/index.html#how-to-use-the-core-library
Privacy: move macros handling to early stage

The patch moves effective visibility computation for macros from `rustc_privacy` to `rustc_resolve`. It will enable this optimization: rust-lang#156228.

However, I found some problems with macro handling while I was doing this. The current implementation was written ~6 years ago and checks the reachability of a definition from a macro by nominal visibility. In general this is incorrect.

For example, in the current implementation modules are not traversed if their nominal visibility is less then the nominal visibility of a module defining macro: https://github.com/rust-lang/rust/blob/29b7590130c83542a095cdf1323ed0f78eec2bb8/compiler/rustc_privacy/src/lib.rs#L618-L626

As a result, in order to compile code like  `tests/ui/definition-reachable/auxiliary/field-method-macro.rs`. we have to additionally traverse types of adt fields: https://github.com/rust-lang/rust/blob/29b7590130c83542a095cdf1323ed0f78eec2bb8/compiler/rustc_privacy/src/lib.rs#L628-L638

This is a hack and the proper solution would be to check definitions with `EffectiveVisibilities::is_reachable`. I haven’t done this yet, as it would start to trigger many lints as more items become reachable. I think it’s better to leave the change to another commit.

r? @petrochenkov
…laumeGomez

rustdoc: Correctness & perf improvements to link-to-definition

Rewrite the way we resolve type-dependent paths (incl. method calls) in `SpanMapVisitor`. Instead of trying to (re)find the enclosing body owner each time we encounter such a node, potentially calling `typeck_body` several times per body, keep track of the "active" `BodyId` in the visitor and cache the corresponding `TypeckResults`. The "active" `BodyId` is updated in `visit_nested_body` (add) and in `visit_item` (remove).

This fixes a class of ICEs where we tried to look up the definition of type-relative paths located in non-body items nested in bodies, in the overarching body which is never correct. rustdoc@main has a hack to fix this issue for paths specifically found in assoc types in impls.

Fixes rust-lang#147882. Fixes rust-lang#147057. Fixes rust-lang#155327. Fixes rust-lang#149089. Fixes rust-lang#150153. Fixes rust-lang#156418.
Supersedes rust-lang#147911.

---

`--generate-link-to-definition` is not enabled by default, so we can't perf this as is. Instead, I'm benching them against PR rust-lang#156348 in PR rust-lang#156355 using the same parent commit for the try-builds. For context, LTD is *extremely* costly as the perf run for the baseline PR shows: rust-lang#156348 (comment).

"Absolute results": rust-lang#156355 (comment).
"Relative results": [https://perf.rust-lang.org/compare.html?...](https://perf.rust-lang.org/compare.html?start=68c2bff6cb08a87e59246064a6a9f37098e22c3f&end=78d15de5525370011388c8f63847e873c4de14ed&stat=instructions%3Au).

Excerpt of the relative results:

Primary:

Benchmark | Profile | Scenario | Backend | Target | % Change | Significance Threshold | Significance Factor
---|---|---|---|---|---|---|---
nalgebra-0.33.0 | doc | full | llvm | x64 | -5.82% | 0.20% | 29.09x
diesel-2.2.10 | doc | full | llvm | x64 | -3.41% | 0.20% | 17.05x
image-0.25.6 | doc | full | llvm | x64 | -2.03% | 0.20% | 10.16x
regex-automata-0.4.8 | doc | full | llvm | x64 | -1.94% | 0.20% | 9.71x
cargo-0.87.1 | doc | full | llvm | x64 | -1.64% | 0.20% | 8.21x
clap_derive-4.5.32 | doc | full | llvm | x64 | -1.63% | 0.20% | 8.14x
cranelift-codegen-0.119.0 | doc | full | llvm | x64 | -1.48% | 0.20% | 7.41x
syn-2.0.101 | doc | full | llvm | x64 | -1.07% | 0.20% | 5.35x
ripgrep-14.1.1 | doc | full | llvm | x64 | -0.96% | 0.20% | 4.78x
stm32f4-0.15.1 | doc | full | llvm | x64 | -0.80% | 0.20% | 4.01x
serde-1.0.219 | doc | full | llvm | x64 | -0.67% | 0.20% | 3.33x
hyper-1.6.0 | doc | full | llvm | x64 | -0.66% | 0.20% | 3.30x
eza-0.21.2 | doc | full | llvm | x64 | -0.55% | 0.20% | 2.74x
unicode-normalization-0.1.24 | doc | full | llvm | x64 | -0.49% | 0.20% | 2.45x
serde_derive-1.0.219 | doc | full | llvm | x64 | -0.45% | 0.20% | 2.26x
typenum-1.18.0 | doc | full | llvm | x64 | -0.42% | 0.20% | 2.08x
bitmaps-3.2.1 | doc | full | llvm | x64 | -0.32% | 0.20% | 1.61x

Secondary:

Benchmark | Profile | Scenario | Backend | Target | % Change | Significance Threshold | Significance Factor
---|---|---|---|---|---|---|---
deep-vector | doc | full | llvm | x64 | -23.96% | 0.20% | 119.78x
large-workspace | doc | full | llvm | x64 | -2.16% | 0.20% | 10.81x
deeply-nested-multi | doc | full | llvm | x64 | -1.35% | 0.20% | 6.75x
serde-1.0.219-threads4 | doc | full | llvm | x64 | -0.67% | 0.20% | 3.33x
wg-grammar | doc | full | llvm | x64 | -0.32% | 0.20% | 1.62x
tt-muncher | opt | full | llvm | x64 | -0.31% | 0.20% | 1.56x

nalgebra-0.33.0:

Query/Function | Time (%) | Time (s) | Time delta | Executions | Executions delta | Hits | Hits delta
---|---|---|---|---|---|---|---
Totals | 109.57% | 2.185 | -0.138 (-5.9%) | 1614146 | -5602 (-0.3%) | 16983840 | -1436455 (-7.8%)
typeck_root | 15.75% | 0.344 | -0.105 (-23.4%) | 1704 | -954 (-35.9%) | 393 | -6758 (-94.5%)
...|...|...|...|...|...|...|...
…Gomez

use `deref_patterns` in `rustdoc` instead of `box_patterns`

Part of rust-lang#156110.
@rust-bors rust-bors Bot added the rollup A PR which is a rollup label May 13, 2026
@rustbot rustbot added A-rustdoc-json Area: Rustdoc JSON backend O-unix Operating system: Unix-like 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. T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output. labels May 13, 2026
@JonathanBrouwer

Copy link
Copy Markdown
Contributor Author

@bors r+ rollup=never p=5

@rust-bors

rust-bors Bot commented May 13, 2026

Copy link
Copy Markdown
Contributor

📌 Commit 65e1e96 has been approved by JonathanBrouwer

It is now in the queue for this repository.

@rust-bors rust-bors Bot 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 May 13, 2026
@rust-bors

rust-bors Bot commented May 13, 2026

Copy link
Copy Markdown
Contributor

⌛ Testing commit 65e1e96 with merge dbb06b7...

Workflow: https://github.com/rust-lang/rust/actions/runs/25819959771

rust-bors Bot pushed a commit that referenced this pull request May 13, 2026
…uwer

Rollup of 5 pull requests

Successful merges:

 - #155521 (Add lint againts invalid runtime symbol definitions)
 - #156500 (Privacy: move macros handling to early stage)
 - #156413 (rustdoc: Correctness & perf improvements to link-to-definition)
 - #156539 (Add `ChildExt::kill_process_group`)
 - #156540 (use `deref_patterns` in `rustdoc` instead of `box_patterns`)
@rust-bors rust-bors Bot 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 May 13, 2026
@rust-bors

rust-bors Bot commented May 13, 2026

Copy link
Copy Markdown
Contributor

This pull request was unapproved due to being closed.

Auto build was cancelled due to the PR being closed. Cancelled workflows:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-rustdoc-json Area: Rustdoc JSON backend O-unix Operating system: Unix-like 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-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.

7 participants