-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Simplify LLVM bitcode linker in bootstrap #142357
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -7,6 +7,7 @@ use llvm::prebuilt_llvm_config; | |
use super::*; | ||
use crate::Flags; | ||
use crate::core::build_steps::doc::DocumentationFormat; | ||
use crate::core::build_steps::tool::LlvmBitcodeLinker; | ||
use crate::core::config::Config; | ||
use crate::utils::tests::git::{GitCtx, git_test}; | ||
|
||
|
@@ -1233,3 +1234,29 @@ fn any_debug() { | |
// Downcasting to the underlying type should succeed. | ||
assert_eq!(x.downcast_ref::<MyStruct>(), Some(&MyStruct { x: 7 })); | ||
} | ||
|
||
/// Check that during a non-cross-compiling stage 2 build, we only compile rustc host tools | ||
/// (such as llvm-bitcode-linker) only once. | ||
#[test] | ||
fn llvm_bitcode_linker_compile_once() { | ||
Comment on lines
+1238
to
+1241
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Question: should we have another test that does check the cross-compiling case, that we do build a stage 1 (rustc, std) pair that can produce artifacts for There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sure, happy to add it. Although from my local experiments, I'm almost sure that bootstrap is actually broken for these situations somehow. Like, There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. And you would be right 🎡 |
||
let mut cache = run_build( | ||
&[], | ||
configure_with_args( | ||
&[ | ||
"build".to_string(), | ||
"--stage".to_string(), | ||
"2".to_string(), | ||
"--set".to_string(), | ||
"rust.llvm-bitcode-linker=true".to_string(), | ||
], | ||
&[TEST_TRIPLE_1], | ||
&[TEST_TRIPLE_2], | ||
), | ||
); | ||
|
||
// Check that llvm-bitcode-linker was built only once, and for host, not target | ||
assert_eq!( | ||
first(cache.all::<LlvmBitcodeLinker>()), | ||
&[LlvmBitcodeLinker { target: TargetSelection::from_user(TEST_TRIPLE_1) }] | ||
); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discussion: maybe
tool_compiler_for_target
? I ask because this should also say something like "it must not be used to build stuff that depends on staged rustc/std", right?Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think there's any requirement like this. It's really just "give me a compiler that can build code for target T". If stage0 could cross-compile for any target, we could use it for this always.
We actually have a bunch of situations like this in bootstrap already, but it was always done sort of implicitly. Here I wanted to make it explicit.
In other words, I think that this could be useful also for other things than just tools. But right now it's only for a single tool, ofc, so happy to rename if you want.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm right. The reason I asked is that
is probably true, just that the "other things" must not use this method if they do "depend on staged compiler/std" (be it through
rustc_private
or directly or somehow).For now, I think it's safer to name this as sth like
tool_compiler_for_target
to make it clear that you should not use it for sth beyond its purpose (because we also haveBuilder::{compiler,compiler_for}
), and then consider its naming if we do use it for not-just-tools, but it's not really a blocking concern.