Externally implementable items #146348

jdonszelmann · 2025-09-08T21:04:17Z

Supersedes #140010
Tracking issue: #125418

Getting started:

#![feature(eii)]

#[eii(eii1)]
pub fn decl1(x: u64) 
// body optional (it's the default)
{
    println!("default {x}");
}

// in another crate, maybe
#[eii1]
pub fn decl2(x: u64) {
    println!("explicit {x}");
}

fn main() {
    decl1(4);
}

tiny perf regression, underlying issue makes multiple things in the compiler slow, not just EII, planning to solve those separately.
No codegen_gcc support, they don't have bindings for weak symbols yet but could
No windows support yet for weak definitions

This PR merges the implementation of EII for just llvm + not windows, doesn't yet contain like a new panic handler implementation or alloc handler. With this implementation, it would support implementing the panic handler in terms of EII already since it requires no default implementation so no weak symbols

The PR has been open in various forms for about a year now, but I feel that having some implementation merged to build upon

jdonszelmann · 2025-09-08T21:12:23Z

compiler/rustc_passes/src/reachable.rs

        // `SymbolExportLevel::Rust` export level but may end up being exported in dylibs.
        || codegen_attrs.flags.contains(CodegenFnAttrFlags::USED_COMPILER)
        || codegen_attrs.flags.contains(CodegenFnAttrFlags::USED_LINKER)
+        // Right now, the only way to get "foreign item symbol aliases" is by being an EII-implementation.


TODO: do we need this:

option 1: we do and implement our own reachability analysis based on it separate from RUSTC_STD_INTERNAL_SYMBOL.

~~option 2: we don't cause we also use RUSTC_STD_INTERNAL_SYMBOL on all EIIs. In that case we should rename STD_INTERNAL_SYMBOL~~

option 3: same as option 2 but maybe we shouldn't use RUSTC_STD_INTERNAL_SYMBOL in the first place; we leave it as-is and create a new flag thta's like it but specifically for EIIs and named something else like RUSTC_USED_BY_NONDIRECT_DEP_CRATE or whatever nicer name we can think of that (as long as it doesn't use STD since it's not really specific to that anymore)

despite STD_INTERNAL_SYMBOL working, and we can test with it for a bit, this is not the way we should do it. i.e. not option 2.

jdonszelmann · 2025-09-08T21:14:02Z

tests/ui/eii/default/local_crate_explicit.rs

+
+#[eii(eii1)]
+pub fn decl1(x: u64) {
+    //~^ WARN function `decl1` is never used


It took me a little bit to decide what is the expected behavior here. We might want to remove this warning. Defaults are in some way expected to be unused. However, here we can prove it because the explicit impl is in the same crate hence the warning.

removing the warning actually makes the code a tiny bit trickier

jdonszelmann · 2025-09-09T20:10:50Z

@bors2 try @rust-timer queue

[DONT MERGE] externally implementable items

rust-bors · 2025-09-09T22:16:01Z

☀️ Try build successful (CI)
Build commit: d5a6633 (d5a66337e06d3b77a1ab8f6793055535195c3ae9, parent: 364da5d88d772fa40fb20353443595385443ac25)

rust-timer · 2025-09-09T23:40:37Z

Finished benchmarking commit (d5a6633): comparison URL.

Overall result: ❌ regressions - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@bors rollup=never
@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.3%	[0.1%, 1.5%]	19
Regressions ❌ (secondary)	0.4%	[0.1%, 1.0%]	44
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.0%	[-0.1%, -0.0%]	4
All ❌✅ (primary)	0.3%	[0.1%, 1.5%]	19

Max RSS (memory usage)

Results (primary 1.7%, secondary 3.9%)

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

	mean	range	count
Regressions ❌ (primary)	1.7%	[0.6%, 2.3%]	6
Regressions ❌ (secondary)	4.7%	[1.1%, 11.2%]	16
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.1%	[-2.9%, -1.2%]	2
All ❌✅ (primary)	1.7%	[0.6%, 2.3%]	6

Cycles

Results (primary 3.1%, secondary -1.3%)

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

	mean	range	count
Regressions ❌ (primary)	3.1%	[3.1%, 3.1%]	1
Regressions ❌ (secondary)	3.2%	[2.5%, 3.6%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.8%	[-4.1%, -2.0%]	9
All ❌✅ (primary)	3.1%	[3.1%, 3.1%]	1

Binary size

Results (primary 0.0%, secondary 0.1%)

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

Bootstrap: 468.052s -> 471.14s (0.66%)
Artifact size: 387.52 MiB -> 390.25 MiB (0.71%)

jdonszelmann · 2025-09-10T02:44:26Z

Well, shit. I think I know some fixes but I hoped this wouldn't happen

compiler/rustc_hir_analysis/src/check/wfcheck.rs

[DONT MERGE] externally implementable items

rust-bors · 2025-11-14T15:51:51Z

☀️ Try build successful (CI)
Build commit: d5ffbde (d5ffbdee89c0da9ce372c94088f7c41d45484cbf, parent: 2fcbda6c1a70606bdb09857e01d01fc6229da712)

rust-timer · 2025-11-14T18:09:54Z

Finished benchmarking commit (d5ffbde): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@bors rollup=never
@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.6%	[0.5%, 0.7%]	4
Regressions ❌ (secondary)	0.3%	[0.1%, 0.8%]	25
Improvements ✅ (primary)	-0.6%	[-1.0%, -0.2%]	2
Improvements ✅ (secondary)	-1.0%	[-1.0%, -1.0%]	1
All ❌✅ (primary)	0.2%	[-1.0%, 0.7%]	6

Max RSS (memory usage)

Results (primary 1.5%, secondary -0.9%)

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

	mean	range	count
Regressions ❌ (primary)	1.5%	[1.5%, 1.5%]	1
Regressions ❌ (secondary)	2.8%	[1.5%, 4.7%]	7
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-7.4%	[-9.4%, -1.3%]	4
All ❌✅ (primary)	1.5%	[1.5%, 1.5%]	1

Cycles

Results (primary 1.4%, secondary 4.3%)

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

	mean	range	count
Regressions ❌ (primary)	1.4%	[1.4%, 1.4%]	1
Regressions ❌ (secondary)	7.1%	[2.1%, 16.3%]	5
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.8%	[-3.0%, -2.6%]	2
All ❌✅ (primary)	1.4%	[1.4%, 1.4%]	1

Binary size

Results (primary 0.0%, secondary 0.1%)

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

Bootstrap: 474.886s -> 480.638s (1.21%)
Artifact size: 391.10 MiB -> 391.84 MiB (0.19%)

rustbot · 2025-11-27T11:07:59Z

Some changes occurred in diagnostic error codes

cc @GuillaumeGomez

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

Some changes occurred in compiler/rustc_builtin_macros/src/autodiff.rs

cc @ZuseZ4

rustbot · 2025-11-27T11:08:01Z

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

lcnr · 2025-11-27T11:10:10Z

r? lcnr

GuillaumeGomez · 2025-11-27T11:10:52Z

compiler/rustc_error_codes/src/error_codes/E0806.md

+fn main() {}
+```
+
+To fix this, `y`'s signature must match that of `x`:


Can you explain why it fails as well please?

bjorn3 · 2025-11-27T11:13:43Z

Did you manage to get weak aliases to work at all on x86_64-pc-windows-gnu? Also I think this is missing the code that allows exporting weak aliases from dylibs on msvc.

jdonszelmann · 2025-11-27T11:18:27Z

So, marked it ready for review. Some updates:

tiny perf regression, underlying issue makes multiple things in the compiler slow, not just EII, planning to solve those separately.
No codegen_gcc support, they don't have bindings for weak symbols yet but could
No windows support yet for weak definitions (@bjorn3)

This PR merges the implementation of EII for just llvm + not windows, doesn't yet contain like a new panic handler implementation or alloc handler. With this implementation, it would support implementing the panic handler in terms of EII already since it requires no default implementation so no weak symbols

The PR has been open in various forms for about a year now, but I feel that having some implementation merged to build upon

bjorn3 · 2025-11-27T11:44:19Z

compiler/rustc_passes/src/eii.rs

@@ -0,0 +1,157 @@
+//! Validity checking for weak lang items


This comment should be updated.

bjorn3 · 2025-11-27T11:46:00Z

compiler/rustc_metadata/src/rmeta/decoder/cstore_impl.rs

+        .map(|(decl_did, (decl, impls))| (
+            decl_did,
+            (decl, impls.into_iter().collect())
+        )).collect()


nit: Please indent the contents of this block. Rustfmt doesn't as this is a macro.

rustbot · 2025-11-27T11:47:26Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

bjorn3 · 2025-11-27T11:49:05Z

If I have an EII with a default body. What symbol names get used. Do callers of the EII use the regular symbol name of the function as symbol to call and does the EII default body get a different name with a weak alias from the regular symbol name to said different name? And for the final implementation of the EII does it directly use the symbol name of the EII or does that also involve a symbol alias. Or is it implemented some other way?

bjorn3 · 2025-11-27T11:51:03Z

Also I'm thinking if perhaps for now we should avoid weak symbols and instead do something similar to the allocator shim for implementing default bodies. And then use weak symbols later as optimization on targets where it actually works.

lcnr

some final nits wrt to the type system parts of this change, otherwise r=me from my end

View changes since this review

lcnr · 2025-11-27T15:28:56Z

compiler/rustc_hir_analysis/src/check/compare_eii.rs

+        ObligationCauseCode::CompareEii { external_impl, declaration },
+    );
+
+    let param_env = ty::ParamEnv::empty();


given that we support implied bounds, should we just use the where-bounds of the declaration here?

I think we should accept some fn foo<'a, 'b: 'a>() even if we don't support generic params

lcnr · 2025-11-27T15:29:27Z

compiler/rustc_hir_analysis/src/check/compare_eii.rs

+    //
+    // FIXME: We manually instantiate the implementation here as we need
+    // to manually compute its implied bounds. Otherwise this could just
+    // be ocx.sub(impl_sig, trait_sig).


comment outdated

we manually instantiate the declaration here to get its implied bounds