Inject `compiler_builtins` during postprocessing and ensure it is made private #135501

tgross35 · 2025-01-14T20:06:42Z

Follow up of #135278

Do the following:

Inject compiler_builtins during postprocessing, rather than injecting extern crate compiler_builtins as _ into the AST
Do not make dependencies of std private by default (this was added in Exclude dependencies of std for diagnostics #135278)
Make sure sysroot crates correctly mark their dependencies private/public
Ensure that marking a dependency private makes its dependents private by default as well, unless otherwise specified
Do the compiler_builtins update that has been blocked on this

There is more detail in the commit messages. This includes the changes I was working on in #136226.

try-job: test-various
try-job: x86_64-msvc-1

tgross35 · 2025-01-14T20:08:48Z

The test still fails, and I cannot chase down how gimli is getting into the sysroot as non-private. Locally I am testing with submodules updated too.

r? bjorn3

bjorn3 · 2025-01-20T15:28:00Z

Maybe you can make the code that checks if a crate is private for diagnostics check if all paths to reach a dependency are private and if so consider the dependency to be private even if the direct dependent crate doesn't mark it as private?

tgross35 · 2025-01-20T19:28:15Z

Do you mean to do that as part of the is_private_dep check?

I am apparently missing some path since exposing more traits in builtins seems to leak into diagnostics still #135560. Haven't looked into it yet, but I suppose that might fix it.

bjorn3 · 2025-01-23T10:29:08Z

Do you mean to do that as part of the is_private_dep check?

Yes

tgross35 · 2025-01-28T21:26:17Z

It looks like the reason compiler_builtins is not showing up as private is because it shows up as an extern crate item with a no-location span, which gets picked up at

rust/compiler/rustc_resolve/src/build_reduced_graph.rs

Line 1321 in 77a4553

self.build_reduced_graph_for_item(item);

. I'm still trying to figure out where this would come from.

tgross35 · 2025-01-28T21:34:11Z

This looks like a possibility

rust/compiler/rustc_builtin_macros/src/standard_library_imports.rs

Lines 49 to 61 in 77a4553

    
           let item = if name == sym::compiler_builtins { 
        
               // compiler_builtins is a private implementation detail. We only 
        
               // need to insert it into the crate graph for linking and should not 
        
               // expose any of its public API. 
        
               // 
        
               // FIXME(#113634) We should inject this during post-processing like 
        
               // we do for the panic runtime, profiler runtime, etc. 
        
               cx.item( 
        
                   span, 
        
                   Ident::new(kw::Underscore, ident_span), 
        
                   thin_vec![], 
        
                   ast::ItemKind::ExternCrate(Some(name)), 
        
               )

Currently, marking a dependency private does not automatically make all its child dependencies private. Resolve this by making its children private by default as well. [1]: rust-lang#135501 (comment)

tgross35 · 2025-01-28T23:25:06Z

@bors try

…, r=<try> Resolve `compiler_builtins` not being treated as private; clean up rust-lang#135278 Follow up of rust-lang#135278 try-job: test-various

Remove the portion of ed63539 that automatically sets crates private based on whether they are dependencies of `std`. Instead, this is controlled by dependency configuration in `Cargo.toml`.

In [1], most dependencies of `std` and other sysroot crates were marked private, but this did not happen for `alloc` and `test`. Update these here, marking public standard library crates as the only non-private dependencies. [1]: rust-lang#111076

Currently, marking a dependency private does not automatically make all its child dependencies private. Resolve this by making its children private by default as well. This also resolves some FIXMEs for tests that are intended to fail but previously passed. [1]: rust-lang#135501 (comment)

The change between 0.1.143 and 0.1.144 includes refactoring that was in compiler-builtins before, but had to be reverted before landing in rust-lang/rust because the traits were leaking into diagnostics [1]. Recently a fix for this issue was merged [2] so the cleanup is reapplied here. This also acts as a regression test for [2]. [1]: rust-lang#128691 (comment) [2]: rust-lang#135278

The recent fixes to private dependencies exposed some cases in the UEFI module where private dependencies are exposed in a public interface. These do not need to be crate-public, so change them to `pub(crate)`.

tgross35 · 2025-01-30T08:46:00Z

@bors try

…, r=<try> Resolve `compiler_builtins` not being treated as private; clean up rust-lang#135278 Follow up of rust-lang#135278 Do the following (one per commit): * Do not make dependencies of `std` private by default * Update remaining sysroot crates to use `public-dependencies` * Ensure that marking a dependency private makes its dependents private by default as well * Do the `compiler_builtins` update that has been blocked on this Based on top of rust-lang#136226 so there are a few preceding commits. try-job: test-various try-job: x86_64-msvc-1

bors · 2025-01-30T08:47:12Z

⌛ Trying commit 530eaf1 with merge 3a63ad6...

bors · 2025-01-30T11:19:50Z

☀️ Try build successful - checks-actions
Build commit: 3a63ad6 (3a63ad61337cad27e2ef4929f21f8989a158f7c3)

tgross35 · 2025-01-30T11:21:12Z

🎉 what a relief. Ready to go, I'm not going to keep #136226 separate since the changes aren't as different as I expected them to be.

@rustbot ready

Update to LLVM 20 LLVM 20 GA is scheduled for March 11th. Rust 1.86 will be stable on April 3rd. * [x] rust-lang#135764 * [x] rust-lang#136134 * [x] rust-lang/compiler-builtins#752 * [ ] llvm/llvm-project#125287 * [ ] Update compiler-builtins (blocked on rust-lang#135501) Tested: host-x86_64, host-aarch64, apple, mingw try-job: x86_64-msvc-1 try-job: i686-msvc-1 try-job: dist-aarch64-msvc try-job: x86_64-msvc-ext1 try-job: x86_64-msvc-ext2 try-job: x86_64-msvc-ext3

[1] has not gone forward, so this needs to be reverted in order to unblock a compiler-builtins upgrade that is is blocking the LLVM 20 upgrade. This reverts commit a2494f1. [1]: rust-lang/rust#135501

[1] has not gone forward, so this needs to be reverted again in order to unblock a compiler-builtins upgrade that is necessary for the LLVM 20 upgrade. This reverts commit a2494f1. [1]: rust-lang/rust#135501

bjorn3 · 2025-02-08T18:28:09Z