Skip to content
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

Merged
merged 1 commit into from
Jul 6, 2017

Conversation

alexcrichton
Copy link
Member

This commit migrates the in-tree libcompiler_builtins to the upstream version
at 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 hidden
    whereas it was only intended to mark exports as hidden.

@rust-highfive
Copy link
Collaborator

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

@alexcrichton
Copy link
Member Author

cc @japaric

@alexcrichton
Copy link
Member Author

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.

@carols10cents carols10cents added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 26, 2017
Copy link
Contributor

@nikomatsakis nikomatsakis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks pretty good to me, but I'm not intimately familiar with how this part of the system is all interconnected. Perhaps @eddyb, @arielb1, or @nagisa wants to take a look?

linkage != llvm::Linkage::PrivateLinkage &&
attr::contains_name(ccx.tcx().hir.krate_attrs(), "compiler_builtins") {
unsafe {
llvm::LLVMRustSetVisibility(lldecl, llvm::Visibility::Hidden);
Copy link
Contributor

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?

Copy link
Member Author

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.

Copy link
Contributor

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];
Copy link
Member

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?

Copy link
Member Author

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") {
Copy link
Member

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()?

Copy link
Member Author

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.

Copy link
Member Author

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
Copy link
Member

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?

@Mark-Simulacrum
Copy link
Member

This needs to also update the init_repo script as in #42928.

@alexcrichton
Copy link
Member Author

@aidanhs mind helping out with that? The failure mode here is that the src/libcompiler_builtins folder is switching from a folder to a git submodule, which I believe the init_repo.sh script doesn't handle just yet. Do you have a suggestion on the best way to fix this? Perhaps just a local workaround to blow away the libcompiler_builtins folder temporarily?

@aidanhs
Copy link
Member

aidanhs commented Jun 27, 2017

I'm not by a computer to try it out, but I think you should just be able to change if [ ! -d "$cache_src_dir/$module" ] to if [ ! -e "$cache_src_dir/$module/.git" ] - this will do a more robust check for a submodule, rather than assuming it's a git repo if the directory exists.

@aidanhs
Copy link
Member

aidanhs commented Jun 27, 2017

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.

@alexcrichton
Copy link
Member Author

@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...

@aidanhs
Copy link
Member

aidanhs commented Jun 27, 2017

@alexcrichton you did -d rather than -e, which won't work on some git versions.

You should also take the final two --recursive additions from https://github.com/rust-lang/rust/pull/42928/files#diff-4c597da51e91a8853ee60a8733858f71 (there's no point doing it when initialising submodules in the cache because they won't be used as a reference).

@alexcrichton
Copy link
Member Author

@bors: r=nikomatsakis

@bors
Copy link
Contributor

bors commented Jun 30, 2017

📌 Commit 809c05c has been approved by nikomatsakis

@aidanhs
Copy link
Member

aidanhs commented Jun 30, 2017

@bors r-

[00:02:39] tidy error: /checkout/src/ci/init_repo.sh:72: line longer than 100 chars
[00:02:40] some tidy checks failed

@alexcrichton alexcrichton force-pushed the compiler-builtins branch 2 times, most recently from eede01e to ae33ff5 Compare June 30, 2017 22:25
@alexcrichton
Copy link
Member Author

@bors: r=nikomatsakis

@bors
Copy link
Contributor

bors commented Jun 30, 2017

📌 Commit ae33ff5 has been approved by nikomatsakis

@bors
Copy link
Contributor

bors commented Jul 1, 2017

⌛ Testing commit ae33ff516b87c336a61a64aac29fcf7188479ecf with merge 0125d49203c5da649b2b4342e02f30f890121f29...

@bors
Copy link
Contributor

bors commented Jul 1, 2017

💔 Test failed - status-appveyor

@kennytm
Copy link
Member

kennytm commented Jul 1, 2017

Failed to build profiler on MSVC. Legit.

error: failed to run custom build command for `profiler_builtins v0.0.0 (file:///C:/projects/rust/src/libprofiler_builtins)`
process didn't exit successfully: `C:\projects\rust\build\x86_64-pc-windows-msvc\stage0-std\release\build\profiler_builtins-7f008c34aad7d625\build-script-build` (exit code: 101)
...
running: "C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\bin\\amd64\\cl.exe" "/nologo" "/MT" "/O2" "/Zl" "/Dstrdup=_strdup" "/Dopen=_open" "/Dfdopen=_fdopen" "/FoC:\\projects\\rust\\build\\x86_64-pc-windows-msvc\\stage0-std\\x86_64-pc-windows-msvc\\release\\build\\profiler_builtins-bcaf90ff1dc76203\\out\\../libcompiler_builtins/compiler-rt/lib/profile\\WindowsMMap.o" "/c" "../libcompiler_builtins/compiler-rt/lib/profile\\WindowsMMap.c"
WindowsMMap.c
../libcompiler_builtins/compiler-rt/lib/profile\WindowsMMap.c(42): error C2065: 'DWORD': undeclared identifier
../libcompiler_builtins/compiler-rt/lib/profile\WindowsMMap.c(42): error C2146: syntax error: missing ';' before identifier 'flProtect'
../libcompiler_builtins/compiler-rt/lib/profile\WindowsMMap.c(42): error C2065: 'flProtect': undeclared identifier
../libcompiler_builtins/compiler-rt/lib/profile\WindowsMMap.c(45): error C2065: 'flProtect': undeclared identifier
...

@bors
Copy link
Contributor

bors commented Jul 6, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: nikomatsakis
Pushing 8cab2c7 to master...

@bors bors merged commit 7e6c9f3 into rust-lang:master Jul 6, 2017
@japaric
Copy link
Member

japaric commented Jul 6, 2017

@alexcrichton you are my hero. 🥇

bors added a commit to rust-lang/compiler-builtins that referenced this pull request Jul 12, 2017
ranweiler added a commit to ranweiler/rust that referenced this pull request Jul 21, 2017
After the work in rust-lang#42899, it no longer auto-discovers it.
ranweiler added a commit to ranweiler/rust that referenced this pull request Jul 21, 2017
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.
Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this pull request Jul 24, 2017
…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.
@alexcrichton alexcrichton deleted the compiler-builtins branch July 24, 2017 23:34
frewsxcv added a commit to frewsxcv/rust that referenced this pull request Feb 17, 2018
`src/compiler-rt` was moved out of tree in rust-lang#42899.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author.
Projects
None yet
Development

Successfully merging this pull request may close these issues.