rust/tests/incremental/lto-in-linker.rs

//@ revisions:cfail1 cfail2
//@ compile-flags: -Z query-dep-graph --crate-type rlib -C linker-plugin-lto -O
//@ no-prefer-dynamic
//@ build-pass

#![feature(rustc_attrs)]
#![rustc_partition_reused(module = "lto_in_linker", cfg = "cfail2")]

pub fn foo() {}
[AUTO_GENERATED] Migrate compiletest to use `ui_test`-style `//@` directives 2024-02-22 12:10:29 +00:00			`//@ revisions:cfail1 cfail2`
			`//@ compile-flags: -Z query-dep-graph --crate-type rlib -C linker-plugin-lto -O`
			`//@ no-prefer-dynamic`
			`//@ build-pass`
Fix disagreeement about CGU reuse and LTO This commit fixes an issue where the codegen backend's selection of LTO disagreed with what the codegen later thought was being done. Discovered in #72006 we have a longstanding issue where if `-Clinker-plugin-lto` in optimized mode is compiled incrementally it will always panic on the second compilation. The underlying issue turned out to be that the production of the original artifact determined that LTO should not be done (because it's being postponed to the linker) but the CGU reuse selection thought that LTO was done so it was trying to load pre-LTO artifacts which were never generated. The fix here is to ensure that the logic when generating code which determines what kind of LTO is being done is shared amongst the CGU reuse decision and the backend actually doing LTO. This means that they'll both be in agreement about whether the previous compilation did indeed produce incremental pre-LTO artifacts. Closes #72006 2020-05-08 09:27:59 -07:00
			`#![feature(rustc_attrs)]`
			`#![rustc_partition_reused(module = "lto_in_linker", cfg = "cfail2")]`

			`pub fn foo() {}`