Remove `src/llvm-emscripten` submodule by alexcrichton · Pull Request #65501 · rust-lang/rust

alexcrichton · 2019-10-17T14:06:08Z

With #65251 landed there's no need to build two LLVM backends and ship
them with rustc, every target we have now uses the same LLVM backend!

This removes the src/llvm-emscripten submodule and additionally
removes all support from rustbuild for building the emscripten LLVM
backend. Multiple codegen backend support is left in place for now, and
this is intended to be an easy 10-15 minute win on CI times by avoiding
having to build LLVM twice.

rust-highfive · 2019-10-17T14:06:19Z

r? @nikomatsakis

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

alexcrichton · 2019-10-17T14:06:25Z

r? @Mark-Simulacrum

Mark-Simulacrum · 2019-10-17T14:10:13Z

We'll also need to drop the submodule from CI: https://github.com/Mark-Simulacrum/rust/blob/7ccf492ae616b4d06eab283ab604938fd234415a/src/ci/init_repo.sh#L50

With that r=me

alexcrichton · 2019-10-17T14:21:32Z

@bors: r=Mark-Simulacrum

bors · 2019-10-17T14:21:34Z

📌 Commit 775af0fa4a63727e954a051d4755ef5587e0a431 has been approved by Mark-Simulacrum

ollie27 · 2019-10-17T14:28:57Z

config.toml.example also needs to be updated:

rust/config.toml.example

Lines 375 to 381 in a16dca3

    
           # This is an array of the codegen backends that will be compiled for the rustc 
        
           # that's being compiled. The default is to only build the LLVM codegen backend, 
        
           # but you can also optionally enable the "emscripten" backend for asm.js or 
        
           # make this an empty array (but that probably won't get too far in the 
        
           # bootstrap) 
        
           # FIXME: remove the obsolete emscripten backend option. 
        
           #codegen-backends = ["llvm"]

bors · 2019-10-19T04:57:26Z

☔ The latest upstream changes (presumably #65570) made this pull request unmergeable. Please resolve the merge conflicts.

…-Simulacrum Remove `src/llvm-emscripten` submodule With #65251 landed there's no need to build two LLVM backends and ship them with rustc, every target we have now uses the same LLVM backend! This removes the `src/llvm-emscripten` submodule and additionally removes all support from rustbuild for building the emscripten LLVM backend. Multiple codegen backend support is left in place for now, and this is intended to be an easy 10-15 minute win on CI times by avoiding having to build LLVM twice.

bors · 2019-10-22T07:40:47Z

☀️ Test successful - checks-azure
Approved by: Mark-Simulacrum
Pushing 50ffa79 to master...

This commit builds on rust-lang#65501 continue to simplify the build system and compiler now that we no longer have multiple LLVM backends to ship by default. Here this switches the compiler back to what it once was long long ago, which is linking LLVM directly to the compiler rather than dynamically loading it at runtime. The `codegen-backends` directory of the sysroot no longer exists and all relevant support in the build system is removed. Note that `rustc` still supports a dynamically loaded codegen backend as it did previously, it just no longer supports dynamically loaded codegen backends in its own sysroot. Additionally as part of this the `librustc_codegen_llvm` crate now once again explicitly depends on all of its crates instead of implicitly loading them through the sysroot. This involved filling out its `Cargo.toml` and deleting all the now-unnecessary `extern crate` annotations in the header of the crate. (this in turn required adding a number of imports for names of macros too). The end results of this change are: * Rustbuild's build process for the compiler as all the "oh don't forget the codegen backend" checks can be easily removed. * Building `rustc_codegen_llvm` is much simpler since it's simply another compiler crate. * Managing the dependencies of `rustc_codegen_llvm` is much simpler since it's "just another `Cargo.toml` to edit" * The build process should be a smidge faster because there's more parallelism in the main rustc build step rather than splitting `librustc_codegen_llvm` out to its own step. * The compiler is expected to be slightly faster by default because the codegen backend does not need to be dynamically loaded. * Disabling LLVM as part of rustbuild is still supported, supporting multiple codegen backends is still supported, and dynamic loading of a codegen backend is still supported.

…r=Mark-Simulacrum rustc: Link LLVM directly into rustc again This commit builds on rust-lang#65501 continue to simplify the build system and compiler now that we no longer have multiple LLVM backends to ship by default. Here this switches the compiler back to what it once was long long ago, which is linking LLVM directly to the compiler rather than dynamically loading it at runtime. The `codegen-backends` directory of the sysroot no longer exists and all relevant support in the build system is removed. Note that `rustc` still supports a dynamically loaded codegen backend as it did previously, it just no longer supports dynamically loaded codegen backends in its own sysroot. Additionally as part of this the `librustc_codegen_llvm` crate now once again explicitly depends on all of its crates instead of implicitly loading them through the sysroot. This involved filling out its `Cargo.toml` and deleting all the now-unnecessary `extern crate` annotations in the header of the crate. (this in turn required adding a number of imports for names of macros too). The end results of this change are: * Rustbuild's build process for the compiler as all the "oh don't forget the codegen backend" checks can be easily removed. * Building `rustc_codegen_llvm` is much simpler since it's simply another compiler crate. * Managing the dependencies of `rustc_codegen_llvm` is much simpler since it's "just another `Cargo.toml` to edit" * The build process should be a smidge faster because there's more parallelism in the main rustc build step rather than splitting `librustc_codegen_llvm` out to its own step. * The compiler is expected to be slightly faster by default because the codegen backend does not need to be dynamically loaded. * Disabling LLVM as part of rustbuild is still supported, supporting multiple codegen backends is still supported, and dynamic loading of a codegen backend is still supported.

This commit builds on rust-lang#65501 continue to simplify the build system and compiler now that we no longer have multiple LLVM backends to ship by default. Here this switches the compiler back to what it once was long long ago, which is linking LLVM directly to the compiler rather than dynamically loading it at runtime. The `codegen-backends` directory of the sysroot no longer exists and all relevant support in the build system is removed. Note that `rustc` still supports a dynamically loaded codegen backend as it did previously, it just no longer supports dynamically loaded codegen backends in its own sysroot. Additionally as part of this the `librustc_codegen_llvm` crate now once again explicitly depends on all of its crates instead of implicitly loading them through the sysroot. This involved filling out its `Cargo.toml` and deleting all the now-unnecessary `extern crate` annotations in the header of the crate. (this in turn required adding a number of imports for names of macros too). The end results of this change are: * Rustbuild's build process for the compiler as all the "oh don't forget the codegen backend" checks can be easily removed. * Building `rustc_codegen_llvm` is much simpler since it's simply another compiler crate. * Managing the dependencies of `rustc_codegen_llvm` is much simpler since it's "just another `Cargo.toml` to edit" * The build process should be a smidge faster because there's more parallelism in the main rustc build step rather than splitting `librustc_codegen_llvm` out to its own step. * The compiler is expected to be slightly faster by default because the codegen backend does not need to be dynamically loaded. * Disabling LLVM as part of rustbuild is still supported, supporting multiple codegen backends is still supported, and dynamic loading of a codegen backend is still supported.

LLVM 7 is over a year old, which should be plenty for compatibility. The last LLVM 6 holdout was llvm-emscripten, which went away in rust-lang#65501. I've also included a fix for LLVM 8 lacking `MemorySanitizerOptions`, which was broken by rust-lang#66522.

Update the minimum external LLVM to 7 LLVM 7 is over a year old, which should be plenty for compatibility. The last LLVM 6 holdout was llvm-emscripten, which went away in rust-lang#65501. I've also included a fix for LLVM 8 lacking `MemorySanitizerOptions`, which was broken by rust-lang#66522.

This commit builds on rust-lang#65501 continue to simplify the build system and compiler now that we no longer have multiple LLVM backends to ship by default. Here this switches the compiler back to what it once was long long ago, which is linking LLVM directly to the compiler rather than dynamically loading it at runtime. The `codegen-backends` directory of the sysroot no longer exists and all relevant support in the build system is removed. Note that `rustc` still supports a dynamically loaded codegen backend as it did previously, it just no longer supports dynamically loaded codegen backends in its own sysroot. Additionally as part of this the `librustc_codegen_llvm` crate now once again explicitly depends on all of its crates instead of implicitly loading them through the sysroot. This involved filling out its `Cargo.toml` and deleting all the now-unnecessary `extern crate` annotations in the header of the crate. (this in turn required adding a number of imports for names of macros too). The end results of this change are: * Rustbuild's build process for the compiler as all the "oh don't forget the codegen backend" checks can be easily removed. * Building `rustc_codegen_llvm` is much simpler since it's simply another compiler crate. * Managing the dependencies of `rustc_codegen_llvm` is much simpler since it's "just another `Cargo.toml` to edit" * The build process should be a smidge faster because there's more parallelism in the main rustc build step rather than splitting `librustc_codegen_llvm` out to its own step. * The compiler is expected to be slightly faster by default because the codegen backend does not need to be dynamically loaded. * Disabling LLVM as part of rustbuild is still supported, supporting multiple codegen backends is still supported, and dynamic loading of a codegen backend is still supported.

rust-highfive assigned nikomatsakis Oct 17, 2019

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 17, 2019

rust-highfive assigned Mark-Simulacrum and unassigned nikomatsakis Oct 17, 2019

alexcrichton force-pushed the remove-emscripten-backend branch from 6f03f1f to 775af0f Compare October 17, 2019 14:21

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 17, 2019

hanna-kruppe mentioned this pull request Oct 17, 2019

Disable Go and OCaml bindings when building LLVM #65201

Merged

Centril mentioned this pull request Oct 17, 2019

Rollup of 7 pull requests #65530

Closed

Centril mentioned this pull request Oct 18, 2019

Rollup of 8 pull requests #65534

Closed

tmandry mentioned this pull request Oct 18, 2019

Rollup of 13 pull requests #65548

Closed

tmandry mentioned this pull request Oct 18, 2019

Rollup of 12 pull requests #65550

Closed

Centril mentioned this pull request Oct 18, 2019

Rollup of 11 pull requests #65559

Closed

Centril mentioned this pull request Oct 19, 2019

Rollup of 7 pull requests #65586

Closed

bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Oct 19, 2019

Centril mentioned this pull request Oct 19, 2019

Rollup of 7 pull requests #65587

Closed

bors added the merged-by-bors This PR was explicitly merged by bors. label Oct 22, 2019

bors merged commit c7d285b into rust-lang:master Oct 22, 2019

bors mentioned this pull request Oct 22, 2019

build-std compatible sanitizer support #65241

Merged

alexcrichton deleted the remove-emscripten-backend branch October 22, 2019 16:07

alexcrichton mentioned this pull request Oct 22, 2019

rustc: Link LLVM directly into rustc again #65703

Closed

Mark-Simulacrum mentioned this pull request Nov 2, 2019

Compile hangs endlessly in LLVM in await-heavy code when ThinLTO is enabled #66036

Closed

est31 mentioned this pull request Nov 16, 2019

Rust platform size (round 2) #65296

Closed

cuviper mentioned this pull request Dec 2, 2019

Update the minimum external LLVM to 7 #66973

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Remove `src/llvm-emscripten` submodule#65501

Remove `src/llvm-emscripten` submodule#65501
bors merged 1 commit intorust-lang:masterfrom
alexcrichton:remove-emscripten-backend

alexcrichton commented Oct 17, 2019

Uh oh!

rust-highfive commented Oct 17, 2019

Uh oh!

alexcrichton commented Oct 17, 2019

Uh oh!

Mark-Simulacrum commented Oct 17, 2019

Uh oh!

alexcrichton commented Oct 17, 2019

Uh oh!

bors commented Oct 17, 2019

Uh oh!

ollie27 commented Oct 17, 2019

Uh oh!

bors commented Oct 19, 2019

Uh oh!

bors commented Oct 22, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

Uh oh!

Conversation

alexcrichton commented Oct 17, 2019

Uh oh!

rust-highfive commented Oct 17, 2019

Uh oh!

alexcrichton commented Oct 17, 2019

Uh oh!

Mark-Simulacrum commented Oct 17, 2019

Uh oh!

alexcrichton commented Oct 17, 2019

Uh oh!

bors commented Oct 17, 2019

Uh oh!

ollie27 commented Oct 17, 2019

Uh oh!

bors commented Oct 19, 2019

Uh oh!

bors commented Oct 22, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants