-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Switch to rust-lang-nursery/compiler-builtins #42899
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
cc @japaric |
Note that some test updates and treatment of LTO are the same fixes as in #42727, just pulled over here as well to get tests passing. |
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.
linkage != llvm::Linkage::PrivateLinkage && | ||
attr::contains_name(ccx.tcx().hir.krate_attrs(), "compiler_builtins") { | ||
unsafe { | ||
llvm::LLVMRustSetVisibility(lldecl, llvm::Visibility::Hidden); |
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.
This seems probably like a better place, but I'm curious: why move this logic here from where it was before?
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.
Ah an excellent question! Sorry this was a bit of a last minute change and forgot to mention it in the PR description. In the previous location this block would set everything with a hidden
visibility, including function imports. What we wanted, however, is only our exported symbols to have hidden
visibility, not the imports we had.
This manifest itself as failures when we tried to import memcpy
as a hidden symbol from libc.so on ARM, which apparently failed. The intention here was to move this logic to where Rust functions are defined, not where every LLVM function is defined.
Is there a better place for this, though? I put it roughtly around where we seemed to extract function attributes and apply LLVM attributes, but I'd be fine placing this elsewhere.
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.
This seems like roughly the right spot to me.
let crate_name = args.windows(2) | ||
.find(|a| &*a[0] == "--crate-name") | ||
.unwrap(); | ||
let crate_name = &*crate_name[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.
Does this work if --crate-name=foo
is used?
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.
No, but Cargo doesn't do that. This is only intended to ever work with Cargo.
// don't want the symbols to get exported. | ||
if linkage != llvm::Linkage::InternalLinkage && | ||
linkage != llvm::Linkage::PrivateLinkage && | ||
attr::contains_name(ccx.tcx().hir.krate_attrs(), "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.
Why not ccx.sess.cstore.is_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.
Because the previous version didn't do that. I'll switch to using it.
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.
Oh that's actually intended for foreign crates, not the local crate.
@@ -8,16 +8,15 @@ | |||
// option. This file may not be copied, modified, or distributed | |||
// except according to those terms. | |||
|
|||
// aux-build:clibrary.rs |
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.
The PR does not remove the clibrary.rs itself, does it?
9c427f1
to
22d25da
Compare
This needs to also update the |
@aidanhs mind helping out with that? The failure mode here is that the |
I'm not by a computer to try it out, but I think you should just be able to change |
As an aside, it does make me a bit sad that nested submodules are enabled unconditionally because it will now pointlessly clone the rust installer test repos. |
22d25da
to
8c5aedd
Compare
@aidanhs ok thanks! I'm now dubious this'll work on the bots, my guess is that the requirement for compiler-builtins to be recursive is going to break this... |
@alexcrichton you did You should also take the final two |
8c5aedd
to
809c05c
Compare
@bors: r=nikomatsakis |
📌 Commit 809c05c has been approved by |
@bors r-
|
eede01e
to
ae33ff5
Compare
@bors: r=nikomatsakis |
📌 Commit ae33ff5 has been approved by |
⌛ Testing commit ae33ff516b87c336a61a64aac29fcf7188479ecf with merge 0125d49203c5da649b2b4342e02f30f890121f29... |
💔 Test failed - status-appveyor |
Failed to build profiler on MSVC. Legit.
|
☀️ Test successful - status-appveyor, status-travis |
@alexcrichton you are my hero. 🥇 |
Don't include custom chkstk on MSVC MSVC includes its own __chkstk so these aren't used. These aren't included in compiler-rt: https://github.com/llvm-mirror/compiler-rt/blob/cb42103777b0fa8b8f38a7bfe5592ed8e3e48388/lib/builtins/CMakeLists.txt#L224-L284. They also weren't included in compiler-builtins: https://github.com/rust-lang/rust/blob/1685c9298685f73db4fe890c1ed27b22408aaad7/src/libcompiler_builtins/build.rs#L255-L293 until rust-lang/rust#42899.
After the work in rust-lang#42899, it no longer auto-discovers it.
The docs for the `compiler_builtins_lib` library feature were removed in rust-lang#42899. But, though the `compiler_builtins` library has been migrated out-of-tree, the feature remains, and is needed to use the stand-alone crate. We reintroduce the docs for the feature, and add a reference to them when describing how to create a `no_std` executable.
…ichton Document use of `compiler_builtins` with `no_std` binaries See discussion in rust-lang#43264. The docs for the `compiler_builtins_lib` feature were removed in PR rust-lang#42899. But, though the `compiler_builtins` library has been migrated out-of-tree, the language feature remains, and is needed to use the stand-alone crate. So, we reintroduce the docs for the feature, and add a reference to them when describing how to create a `no_std` executable.
`src/compiler-rt` was moved out of tree in rust-lang#42899.
This commit migrates the in-tree
libcompiler_builtins
to the upstream versionat https://github.com/rust-lang-nursery/compiler-builtins. The upstream version
has a number of intrinsics written in Rust and serves as an in-progress rewrite
of compiler-rt into Rust. Additionally it also contains all the existing
intrinsics defined in
libcompiler_builtins
for 128-bit integers.It's been the intention since the beginning to make this transition but
previously it just lacked the manpower to get done. As this PR likely shows it
wasn't a trivial integration! Some highlight changes are:
The PR Test with the 'c' feature enabled on CI compiler-builtins#166 contains a number of fixes
across platforms and also some refactorings to make the intrinsics easier to
read. The additional testing added there also fixed a number of integration
issues when pulling the repository into this tree.
LTO with the compiler-builtins crate was fixed to link in the entire crate
after the LTO process as these intrinsics are excluded from LTO.
Treatment of hidden symbols was updated as previously the
#![compiler_builtins]
crate would mark all symbol imports as hiddenwhereas it was only intended to mark exports as hidden.