Replace weak only lang items with a custom attribute by Urgau · Pull Request #159344 · rust-lang/rust

Urgau · 2026-07-15T16:33:29Z

When I added the invalid_runtime_symbol_definitions and suspicious_runtime_symbol_definitions lints in #155521 I added the concept of "weak only" lang item.

It's a LangItem that has no implementation, this is useful because the core symbols where not directly called, they were inserted by the compiler.

This mechanism work well, but T-lang approved the extension to "all extern functions referenced by the standard library", which makes the lang item approach impractical as we needs to update 5 files just to declare them. I'm not sure we can ask library contributor to do the dance for each extern "C" functions.

But the most problematic thing is that many extern functions in std come from libc not std, and adding lang items there is just no feasible I think.

Instead this PR proposed that we introduce a proper mechanism for them by adding a attribute #[rustc_canonical_symbol = "..."], which is encoded and decoded in rmeta like lang items and diagnostics items.

This simplifies the declaration as we only need to put the attribute to be effective #[rustc_canonical_symbol = "open"]. It also opens up many possibilities (none implemented here) like putting them on use statements (so we don't need to modify libc) or having the attribute be placed on a module. The table may also be useful on it's own if we want someday to do it for all crates, not just the standard library.

Follow up to #155521 and #158522

rustbot · 2026-07-15T16:33:32Z

Some changes occurred in compiler/rustc_hir/src/attrs

cc @jdonszelmann, @JonathanBrouwer

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann, @JonathanBrouwer

Some changes occurred in compiler/rustc_passes/src/check_attr.rs

cc @jdonszelmann, @JonathanBrouwer

rustbot · 2026-07-15T16:33:34Z

r? @jackh726

rustbot has assigned @jackh726.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: compiler
compiler expanded to 75 candidates
Random selection from 19 candidates

mejrs · 2026-07-16T23:07:27Z

What is the reason for the name field, can't this be a word attribute like #[rustc_canonical_symbol]? Only the tests have a case where the name is different from the item.

Urgau · 2026-07-17T17:52:23Z

What is the reason for the name field

Calling the symbol_name query can be quite expensive, in particular when done repeatedly, but you're right that the name field could probably just be deduced (and maybe should).

Let's do a perf run without it.
@bors try @rust-timer queue

Replace weak only lang items with a custom attribute

rust-bors · 2026-07-17T20:00:48Z

☀️ Try build successful (CI)
Build commit: 9809522 (9809522494587bd84b1cae60f99fb7080a2a2ec1)
Base parent: 656ccbe (656ccbe796ff98def9b555c118e1620c5389e3b2)

rust-timer · 2026-07-17T21:18:18Z

Finished benchmarking commit (9809522): comparison URL.

Overall result: ❌ regressions - please read:

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

@bors rollup=never rustc-perf
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.3%	[0.1%, 0.6%]	10
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.4%	[-0.4%, -0.4%]	1
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary -4.3%, secondary 0.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	4.3%	[1.1%, 6.5%]	7
Improvements ✅ (primary)	-4.3%	[-6.2%, -2.5%]	3
Improvements ✅ (secondary)	-4.2%	[-6.0%, -2.0%]	7
All ❌✅ (primary)	-4.3%	[-6.2%, -2.5%]	3

Cycles

This perf run didn't have relevant results for this metric.

Binary size

Results (primary 0.0%, secondary 0.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	0.0%	[0.0%, 0.0%]	27
Regressions ❌ (secondary)	0.0%	[0.0%, 0.1%]	6
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.0%	[0.0%, 0.0%]	27

Bootstrap: 490.561s -> 491.765s (0.25%)
Artifact size: 390.05 MiB -> 389.50 MiB (-0.14%)

Urgau · 2026-07-18T12:34:19Z

I've switch to deducing the symbol name in the latest commit. Let's see if it has a perf impact.

@bors try @rust-timer queue

Replace weak only lang items with a custom attribute

rust-bors · 2026-07-18T14:52:50Z

☀️ Try build successful (CI)
Build commit: 4c682e3 (4c682e32f0cd928dd72d1e25402074a8cf953a8f)
Base parent: b26c8ef (b26c8ef0535b2de24a0af4048370caf449eebabd)

rust-timer · 2026-07-18T15:47:46Z

Finished benchmarking commit (4c682e3): comparison URL.

Overall result: ❌ regressions - please read:

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

@bors rollup=never rustc-perf
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

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

Max RSS (memory usage)

Results (secondary 1.2%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	5.6%	[2.4%, 9.5%]	5
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.3%	[-5.3%, -2.1%]	4
All ❌✅ (primary)	-	-	0

Cycles

This perf run didn't have relevant results for this metric.

Binary size

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

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.0%	[0.0%, 0.0%]	1
Improvements ✅ (primary)	-0.0%	[-0.0%, -0.0%]	10
Improvements ✅ (secondary)	-0.1%	[-0.1%, -0.0%]	4
All ❌✅ (primary)	-0.0%	[-0.0%, -0.0%]	10

Bootstrap: 492.122s -> 488.922s (-0.65%)
Artifact size: 389.50 MiB -> 389.47 MiB (-0.01%)

rustbot · 2026-07-19T15:49:49Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

Urgau · 2026-07-19T17:25:10Z

@bors r=mejrs

rust-bors · 2026-07-19T17:25:13Z

📌 Commit deac9ea has been approved by mejrs

It is now in the queue for this repository.

Replace weak only lang items with a custom attribute When I added the `invalid_runtime_symbol_definitions` and `suspicious_runtime_symbol_definitions` lints in #155521 I added the concept of "weak only" lang item. It's a `LangItem` that has no implementation, this is useful because the `core` symbols where not directly called, they were inserted by the compiler. This mechanism work well, but T-lang [approved](#158522 (comment)) the extension to "all extern functions referenced by the standard library", which makes the lang item approach impractical as we needs to update 5 files just to declare them. I'm not sure we can ask library contributor to do the dance for each `extern "C"` functions. But the most problematic thing is that many extern functions in `std` come from `libc` not `std`, and adding lang items there is just no feasible I think. Instead this PR proposed that we introduce a proper mechanism for them by adding a attribute `#[rustc_canonical_symbol = "..."]`, which is encoded and decoded in `rmeta` like lang items and diagnostics items. This simplifies the declaration as we only need to put the attribute to be effective `#[rustc_canonical_symbol = "open"]`. It also opens up many possibilities (none implemented here) like putting them on `use` statements (so we don't need to modify `libc`) or having the attribute be placed on a module. The table may also be useful on it's own if we want someday to do it for all crates, not just the standard library. Follow up to #155521 and #158522

rust-bors · 2026-07-19T20:07:39Z

💔 Test for 1003648 failed: CI. Failed job:

auto - x86_64-mingw-2 (web logs, enhanced plaintext logs)

JonathanBrouwer · 2026-07-19T20:15:07Z

@bors retry

Replace weak only lang items with a custom attribute When I added the `invalid_runtime_symbol_definitions` and `suspicious_runtime_symbol_definitions` lints in #155521 I added the concept of "weak only" lang item. It's a `LangItem` that has no implementation, this is useful because the `core` symbols where not directly called, they were inserted by the compiler. This mechanism work well, but T-lang [approved](#158522 (comment)) the extension to "all extern functions referenced by the standard library", which makes the lang item approach impractical as we needs to update 5 files just to declare them. I'm not sure we can ask library contributor to do the dance for each `extern "C"` functions. But the most problematic thing is that many extern functions in `std` come from `libc` not `std`, and adding lang items there is just no feasible I think. Instead this PR proposed that we introduce a proper mechanism for them by adding a attribute `#[rustc_canonical_symbol = "..."]`, which is encoded and decoded in `rmeta` like lang items and diagnostics items. This simplifies the declaration as we only need to put the attribute to be effective `#[rustc_canonical_symbol = "open"]`. It also opens up many possibilities (none implemented here) like putting them on `use` statements (so we don't need to modify `libc`) or having the attribute be placed on a module. The table may also be useful on it's own if we want someday to do it for all crates, not just the standard library. Follow up to #155521 and #158522

JonathanBrouwer · 2026-07-19T21:27:00Z

@bors yield

rust-bors · 2026-07-19T21:27:04Z

Auto build was cancelled. Cancelled workflows:

https://github.com/rust-lang/rust/actions/runs/29703630752

The next pull request likely to be tested is #159579.

Replace weak only lang items with a custom attribute When I added the `invalid_runtime_symbol_definitions` and `suspicious_runtime_symbol_definitions` lints in #155521 I added the concept of "weak only" lang item. It's a `LangItem` that has no implementation, this is useful because the `core` symbols where not directly called, they were inserted by the compiler. This mechanism work well, but T-lang [approved](#158522 (comment)) the extension to "all extern functions referenced by the standard library", which makes the lang item approach impractical as we needs to update 5 files just to declare them. I'm not sure we can ask library contributor to do the dance for each `extern "C"` functions. But the most problematic thing is that many extern functions in `std` come from `libc` not `std`, and adding lang items there is just no feasible I think. Instead this PR proposed that we introduce a proper mechanism for them by adding a attribute `#[rustc_canonical_symbol = "..."]`, which is encoded and decoded in `rmeta` like lang items and diagnostics items. This simplifies the declaration as we only need to put the attribute to be effective `#[rustc_canonical_symbol = "open"]`. It also opens up many possibilities (none implemented here) like putting them on `use` statements (so we don't need to modify `libc`) or having the attribute be placed on a module. The table may also be useful on it's own if we want someday to do it for all crates, not just the standard library. Follow up to #155521 and #158522

rust-bors · 2026-07-20T00:44:14Z

⌛ Testing commit deac9ea with merge adce1b0...

rust-bors · 2026-07-20T00:44:29Z

⌛ Testing commit deac9ea with merge adce1b0...

rust-log-analyzer · 2026-07-20T03:03:35Z

The job x86_64-mingw-1 failed! Check out the build log: (web) (plain enhanced) (plain)

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

Bootstrap failed while executing `test --stage 2 --skip=compiler --skip=src`
Currently active steps:
test::Crate { build_compiler: Compiler { stage: 2, host: x86_64-pc-windows-gnu, forced_compiler: false }, target: x86_64-pc-windows-gnu, mode: Std, crates: ["alloc", "alloctests", "compiler_builtins", "core", "coretests", "panic_abort", "panic_unwind", "proc_macro", "rustc-std-workspace-core", "std", "std_detect", "sysroot", "test", "unwind"] } at src\bootstrap\src\core\build_steps\test.rs:3361
Build completed unsuccessfully in 2:11:18
make: *** [Makefile:126: ci-mingw-x] Error 1
  local time: Mon Jul 20 03:03:09 CUT 2026
  network time: Mon, 20 Jul 2026 03:03:14 GMT
##[error]Process completed with exit code 2.
##[group]Run echo "disk usage:"
echo "disk usage:"

rust-bors · 2026-07-20T03:08:33Z

💔 Test for adce1b0 failed: CI. Failed job:

auto - x86_64-mingw-1 (web logs, enhanced plaintext logs)

rustbot added the A-attributes Area: Attributes (`#[…]`, `#![…]`) label Jul 15, 2026

rustbot assigned jackh726 Jul 15, 2026

rustbot added 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. labels Jul 15, 2026

This comment has been minimized.

Sign in to view

Urgau force-pushed the canonical-symbols branch 2 times, most recently from 475f1bc to 89cc3a5 Compare July 15, 2026 17:48

This comment has been minimized.

Sign in to view

rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jul 17, 2026

This comment has been minimized.

Sign in to view

rust-bors Bot pushed a commit that referenced this pull request Jul 17, 2026

Auto merge of #159344 - Urgau:canonical-symbols, r=<try>

9809522

Replace weak only lang items with a custom attribute

This comment has been minimized.

Sign in to view

rustbot added perf-regression Performance regression. and removed S-waiting-on-perf Status: Waiting on a perf run to be completed. labels Jul 17, 2026

This comment has been minimized.

Sign in to view

rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jul 18, 2026

This comment has been minimized.

Sign in to view

rust-bors Bot pushed a commit that referenced this pull request Jul 18, 2026

Auto merge of #159344 - Urgau:canonical-symbols, r=<try>

4c682e3

Replace weak only lang items with a custom attribute

This comment has been minimized.

Sign in to view

rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jul 18, 2026

Urgau added 5 commits July 19, 2026 17:38

Query-fy and encode canonical symbols

8e6bd6e

Mark #[rustc_canonical_symbol] items as used

6702d70

Use #[rustc_canonical_symbol] instead of lang-items

4cc1a3c

Remove now unused runtime symbols and weak only lang items

4d413ed

Compute the symbol name instead of requiring it for canonical symbols

deac9ea

Urgau force-pushed the canonical-symbols branch from 0a4dcfc to deac9ea Compare July 19, 2026 15:49

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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 19, 2026

This comment has been minimized.

Sign in to view

rust-bors Bot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 19, 2026

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 Jul 19, 2026

This comment has been minimized.

Sign in to view

rust-bors Bot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 20, 2026

Uh oh!

Uh oh!

Conversation

Urgau commented Jul 15, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jul 15, 2026

Uh oh!

rustbot commented Jul 15, 2026

Uh oh!

This comment has been minimized.

mejrs commented Jul 16, 2026

Uh oh!

Urgau commented Jul 17, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

rust-bors Bot commented Jul 17, 2026

Uh oh!

This comment has been minimized.

rust-timer commented Jul 17, 2026

Overall result: ❌ regressions - please read:

Uh oh!

Urgau commented Jul 18, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

rust-bors Bot commented Jul 18, 2026

Uh oh!

This comment has been minimized.

rust-timer commented Jul 18, 2026

Overall result: ❌ regressions - please read:

Uh oh!

rustbot commented Jul 19, 2026

Uh oh!

Urgau commented Jul 19, 2026

Uh oh!

rust-bors Bot commented Jul 19, 2026

Uh oh!

This comment has been minimized.

rust-bors Bot commented Jul 19, 2026

Uh oh!

JonathanBrouwer commented Jul 19, 2026

Uh oh!

This comment has been minimized.

JonathanBrouwer commented Jul 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rust-bors Bot commented Jul 19, 2026

Uh oh!

rust-bors Bot commented Jul 20, 2026

Uh oh!

rust-bors Bot commented Jul 20, 2026

Uh oh!

rust-log-analyzer commented Jul 20, 2026

Uh oh!

rust-bors Bot commented Jul 20, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

Urgau commented Jul 15, 2026 •

edited by rustbot

Loading

JonathanBrouwer commented Jul 19, 2026 •

edited

Loading