-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Make the c
feature for compiler-builtins
an explicit opt-in
#101833
Conversation
(rust-highfive has picked a reviewer for you, use r? to override) |
0592216
to
2da1286
Compare
2da1286
to
c3675ed
Compare
c3675ed
to
405f0c2
Compare
This comment has been minimized.
This comment has been minimized.
405f0c2
to
2959eec
Compare
This comment has been minimized.
This comment has been minimized.
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
Some changes occurred in src/tools/cargo cc @ehuss |
3328c50
to
4398aff
Compare
dist-various-2 works except for the very last step, after the build:
I think it's just not meant to run in PR CI and it's fine. So this PR should be good to go after I revert the CI changes :) |
dd13636
to
f8527fd
Compare
I'm a little worried that e.g. distros won't turn this on even if they can and end up with slower builds as a result. Not sure it's worth being too concerned about though. I think we can re-assess if we run into trouble as a result of this; if needed we can flip the default. I'll flag as relnotes so we can mention it in internal changes/compat notes, I think. @bors r+ |
??? will dig into this later |
This comment has been minimized.
This comment has been minimized.
The build script for `compiler_builtins` doesn't support cross-compilation. I tried fixing it, but the cc crate itself doesn't appear to support cross-compiling to windows either unless you use the -gnu toolchain: ``` error occurred: Failed to find tool. Is `lib.exe` installed? ``` Rather than trying to fix it or special-case the platforms without bugs, make it opt-in instead of automatic.
f8527fd
to
3acb505
Compare
@bors r=Mark-Simulacrum |
☀️ Test successful - checks-actions |
Finished benchmarking commit (bf40408): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Footnotes |
// still want to install it, as it otherwise won't be available. | ||
return false; | ||
} | ||
if !builder.is_rust_llvm(target) { |
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.
Please revert this. The point of is_rust_llvm
is to know whether it contains Rust patches. In #101072 I added a config option so you can use a vanilla upstream LLVM without affecting other parts of how bootstrap works, this breaks that by re-coupling the idea of "is patched" to "is in tree".
let compiler_builtins_root = builder.src.join("src/llvm-project/compiler-rt"); | ||
let compiler_builtins_c_feature = if compiler_builtins_root.exists() { | ||
let compiler_builtins_c_feature = if builder.config.optimized_compiler_builtins { | ||
if !builder.is_rust_llvm(target) { |
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.
Likewise, this should be checking if a source checkout of LLVM is being used. It shouldn't be affected by the llvm-has-rust-patches
target option.
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 think is_rust_llvm
is exactly what we want here, actually. We want to know that if we use the sources in src/llvm-project
, the instrumentation there will match the instrumentation in libLLVM.so, which is true exactly when that has the same patches as the submodule. Whether it was originally built from source or not shouldn't matter.
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.
Yeah you want to know if the versions match, which isn't the same as whether you're building from source.. it also isn't the same as whether it includes Rust patches, though. I commented on the other PR
I want to note that disabling the At least on the (I discovered this when pulling the latest changes into Ferrocene) |
panic!( | ||
"need a managed LLVM submodule for optimized intrinsics support; unset `llvm-config` or `optimized-compiler-builtins`" | ||
); |
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.
If this check is present, there has to be a way to provide the path to the compiler-rt
source code of the custom LLVM, otherwise it will be impossible to use custom LLVMs on some platforms (see #101833 (comment)).
What I would do is have a check like:
if optimized_compiler_builtins && (!is_rust_llvm() || compiler_rt_src_path)
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.
Do you mean
if optimized_compiler_builtins && !(is_rust_llvm() || compiler_rt_src_path)
?
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.
Yep, sorry!
…f inferred" This reverts commit 3acb505 (PR rust-lang#101833). The changes in this commit caused several bugs or at least incompatibilies. For now we're reverting this commit and will re-land it alongside fixes for those bugs.
…iltins, r=jyn514 Revert "Make the `c` feature for `compiler-builtins` opt-in instead of inferred" This reverts commit 3acb505 (PR rust-lang#101833). The changes in this commit caused several bugs/incompatibilities (rust-lang#101833 (comment), rust-lang#102560). For now we're reverting this commit and will re-land it alongside fixes for those bugs. Re-opens rust-lang#101172 cc rust-lang#102560 cc rust-lang#102579
Its build script doesn't support cross-compilation. I tried fixing it, but the cc crate itself doesn't appear to support cross-compiling to windows either unless you use the -gnu toolchain:
Fixes #101172.