about summary refs log tree commit diff
path: root/src/rustc/Cargo.toml
AgeCommit message (Collapse)AuthorLines
2020-08-30mv compiler to compiler/mark-25/+0
2020-01-09Remove unused dependenciesShotaro Yamada-1/+0
2019-12-11rustc: Link LLVM directly into rustc againAlex Crichton-0/+1
This commit builds on #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.
2019-03-26Update jemalloc-sys to version 0.3.0gnzlbg-1/+1
2019-01-03rustc: Fix regression where jemalloc isn't usedAlex Crichton-0/+1
In #56986 the linkage of jemalloc to the compiler was switched from the driver library to the rustc binary to ensure that only rustc itself uses jemalloc. In doing so, however, it turns out jemalloc wasn't actually linked in at all! None of the symbols were referenced so the static library wasn't used. This means that jemalloc wasn't pulled in at all. This commit performs a bit of a dance to reference jemalloc symbols, attempting to pull it in despite LLVM's optimizations. Closes #57115
2018-12-19rustc: Move jemalloc from rustc_driver to rustcAlex Crichton-1/+6
This commit moves jemalloc to just the rustc binary rather than the rustc_driver shared library, enusring that it's only used for binaries that opt-in to it like rustc rather than other binaries using librustc_driver like rustdoc/rls/etc. This will hopefully address #56980
2018-11-22Move fake rustc_codegen_ssa dependency from rustc_driver to rustc-mainbjorn3-0/+4
2018-11-02Use `jemalloc-sys` on Linux and OSX compilersAlex Crichton-0/+3
This commit adds opt-in support to the compiler to link to `jemalloc` in the compiler. When activated the compiler will depend on `jemalloc-sys`, instruct jemalloc to unprefix its symbols, and then link to it. The feature is activated by default on Linux/OSX compilers for x86_64/i686 platforms, and it's not enabled anywhere else for now. We may be able to opt-in other platforms in the future! Also note that the opt-in only happens on CI, it's otherwise unconditionally turned off by default. Closes #36963
2018-11-02Remove all jemalloc-related contentAlex Crichton-3/+0
This commit removes all jemalloc related submodules, configuration, etc, from the bootstrap, from the standard library, and from the compiler. This will be followed up with a change to use jemalloc specifically as part of rustc on blessed platforms.
2018-05-17Fix rustc binary metadata overwriting librustc metadataMark Simulacrum-1/+1
In #49289, rustc was changed to emit metadata for binaries, which made it so that the librustc.rmeta file created when compiling librustc was overwritten by the rustc-main compilation. This commit renames the rustc-main binary to avoid this problem. https://github.com/rust-lang/cargo/issues/5524 has also been filed to see if Cargo can learn to warn on this situation instead of leaving it for the user to debug.
2018-04-26Rename rustc_back::target to rustc_target::spec.Irina Popa-2/+2
2018-01-27rustc: Load the `rustc_trans` crate at runtimeAlex Crichton-3/+0
Building on the work of # 45684 this commit updates the compiler to unconditionally load the `rustc_trans` crate at runtime instead of linking to it at compile time. The end goal of this work is to implement # 46819 where rustc will have multiple backends available to it to load. This commit starts off by removing the `extern crate rustc_trans` from the driver. This involved moving some miscellaneous functionality into the `TransCrate` trait and also required an implementation of how to locate and load the trans backend. This ended up being a little tricky because the sysroot isn't always the right location (for example `--sysroot` arguments) so some extra code was added as well to probe a directory relative to the current dll (the rustc_driver dll). Rustbuild has been updated accordingly as well to have a separate compilation invocation for the `rustc_trans` crate and assembly it accordingly into the sysroot. Finally, the distribution logic for the `rustc` package was also updated to slurp up the trans backends folder. A number of assorted fallout changes were included here as well to ensure tests pass and such, and they should all be commented inline.
2017-08-11Make librustc_driver work without librustc_transbjorn3-0/+1
2017-07-27Build rustdoc on-demand.Mark Simulacrum-5/+0
Rustdoc is no longer compiled in every stage, alongside rustc, instead it is only compiled when requested, and generally only for the last stage.
2016-11-30Update the bootstrap compilerAlex Crichton-11/+0
Now that we've got a beta build, let's use it!
2016-05-12rustbuild: Add support for crate tests + doctestsAlex Crichton-0/+2
This commit adds support to rustbuild to run crate unit tests (those defined by `#[test]`) as well as documentation tests. All tests are powered by `cargo test` under the hood. Each step requires the `libtest` library is built for that corresponding stage. Ideally the `test` crate would be a dev-dependency, but for now it's just easier to ensure that we sequence everything in the right order. Currently no filtering is implemented, so there's not actually a method of testing *only* libstd or *only* libcore, but rather entire swaths of crates are tested all at once. A few points of note here are: * The `coretest` and `collectionstest` crates are just listed as `[[test]]` entires for `cargo test` to naturally pick up. This mean that `cargo test -p core` actually runs all the tests for libcore. * Libraries that aren't tested all mention `test = false` in their `Cargo.toml` * Crates aren't currently allowed to have dev-dependencies due to rust-lang/cargo#860, but we can likely alleviate this restriction once workspaces are implemented. cc #31590
2016-03-08rustbuild: Fix stage1 rustdocAlex Crichton-1/+1
Just always build stage1 rustdoc, it's really not that much more to build as it's essentially just one library.
2016-03-08rustbuild: Move rustbook to a `src/tools` directoryAlex Crichton-5/+0
We've actually got quite a few tools that are compiled as part of our build, let's start housing them all in a `tools` directory.
2016-02-11Add a Cargo-based build systemAlex Crichton-0/+36
This commit is the start of a series of commits which start to replace the makefiles with a Cargo-based build system. The aim is not to remove the makefiles entirely just yet but rather just replace the portions that invoke the compiler to do the bootstrap. This commit specifically adds enough support to perform the bootstrap (and all the cross compilation within) along with generating documentation. More commits will follow up in this series to actually wire up the makefiles to call this build system, so stay tuned!