Inject compiler_builtins during postprocessing rather than via AST

[tgross35]

compiler_builtins is currently injected into the AST as extern crate compiler_builtins as _. This has made gating via diagnostics difficult because it appears in the crate graph as a non-private dependency, and there isn't an easy way to differentiate between the injected AST and user-specified extern crate compiler_builtins.

Resolve this by injecting compiler_builtins during postprocessing rather than early in the AST. Most of the time this isn't even needed because it shows up in std or core's crate graph, but injection is still needed to ensure #![no_core] works correctly.

A similar change was attempted at 1 but this encountered errors building proc_macro and rustc-std-workspace-std. Similar failures showed up while working on this patch, which were traced back to compiler_builtins showing up in the graph twice (once via dependency and once via injection). This is resolved by not injecting if a #![compiler_builtins] crate already exists.

This PR is a smaller subset of changes, split from #135501. #135501 builds on this to resolve a couple remaining privacy issues and actually do the update that has been troublesome.

try-job: aarch64-gnu
try-job: dist-x86_64-linux
try-job: i686-mingw
try-job: x86_64-gnu-distcheck
try-job: x86_64-msvc-1
try-job: x86_64-rust-for-linux
try-job: test-various

[rustbot]

r? @petrochenkov

rustbot has assigned @petrochenkov.
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

[tgross35]

The current bug is that compiler_builtins depends on rustc_std_workspace_core, which for some reason is resolving its dependency core with a different cnum than the first time core was loaded. I think this is the same behavior @Amanieu was running into at #113634 (comment).

 INFO rustc_metadata::creader POSTPROCESS
 INFO rustc_metadata::creader resolving crate `compiler_builtins`
 INFO rustc_metadata::creader falling back to a load
 INFO rustc_metadata::creader register newly loaded library for `compiler_builtins`
 INFO rustc_metadata::creader register crate `compiler_builtins` (cnum = 14. private_dep = true)
 INFO rustc_metadata::creader resolving dep `compiler_builtins`->`rustc_std_workspace_core` hash: `f67002fa0554298ad26d2bf8107374d1` extra filename: `-0f3268257eb1faf9`
 INFO rustc_metadata::creader resolving crate `rustc_std_workspace_core`
 INFO rustc_metadata::creader falling back to a load
 INFO rustc_metadata::creader register newly loaded library for `rustc_std_workspace_core`
 INFO rustc_metadata::creader register crate `rustc_std_workspace_core` (cnum = 15. private_dep = false)
 INFO rustc_metadata::creader resolving dep `rustc_std_workspace_core`->`core` hash: `fc48f0a1c1d99c8755223ff791e4cabc` extra filename: `-af66f1d2fa6253c2`
 INFO rustc_metadata::creader resolving crate `core`
 INFO rustc_metadata::creader falling back to a load
 INFO rustc_metadata::creader register newly loaded library for `core`
 INFO rustc_metadata::creader returning false for core is private
 INFO rustc_metadata::creader register crate `core` (cnum = 16. private_dep = false)
 INFO rustc_metadata::creader resolving dep `compiler_builtins`->`core` hash: `fc48f0a1c1d99c8755223ff791e4cabc` extra filename: `-af66f1d2fa6253c2`
 INFO rustc_metadata::creader resolving crate `core`
 INFO rustc_metadata::creader library for `core` was loaded previously, cnum 16
 INFO rustc_metadata::creader returning false for core is private
 INFO rustc_metadata::creader panic runtime injection skipped, only generating rlib

[tgross35]

Actually it looks like compiler_builtins is getting loaded twice, once as a dependency of std and once via injection, which gives it two different hashes. Going to try skipping injection if it is already in the graph.

edit: trying that here #136234

[tgross35]

@bors try

[tgross35]

@bors try

[bors]

⌛ Trying commit 55facbb with merge a3ee377...

[bors]

💔 Test failed - checks-actions

[tgross35]

...so close.

All of the failed tests build staticlibs, postprocessing must not run with that option.

[tgross35]

It looks like Implicit means it doesn't get linked in static libs

rust/compiler/rustc_metadata/src/dependency_format.rs

Lines 350 to 362 in e6f12c8

	// All crates are available in an rlib format, so we're just going to link
	// everything in explicitly so long as it's actually required.
	let mut ret = IndexVec::new();
	assert_eq!(ret.push(Linkage::Static), LOCAL_CRATE);
	for &cnum in tcx.crates(()) {
	assert_eq!(
	ret.push(match tcx.dep_kind(cnum) {
	CrateDepKind::Explicit => Linkage::Static,
	CrateDepKind::MacrosOnly | CrateDepKind::Implicit => Linkage::NotLinked,
	}),
	cnum
	);
	}

. Trying again with implicit -> explicit.

@bors try

[bors]

⌛ Trying commit 0112499 with merge 9bd0b76...

[bors]

☀️ Try build successful - checks-actions
Build commit: 9bd0b76 (9bd0b76dacf5bdb1e1667d010cfd6e26268dcc36)

[tgross35]

#135501 includes this PR plus the couple of remaining changes to make the update actually work. Since the difference between the two is reasonably small, I am going to close this PR in favor of that one (fyi @petrochenkov if you were planning to review).