https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.41.0 2019-12-11T14:50:11+00:00 2019-12-11T14:50:11+00:00 Alex Crichton alex@alexcrichton.com 2019-10-22T15:51:35+00:00 urn:sha1:7f23e6e8d7479d8a430e007fab9b195b7ea0d261 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-04-22T16:01:33+00:00 varkor github@varkor.com 2019-04-22T14:50:02+00:00 urn:sha1:9736d32f842d1f35b218f4fae219f61460d30607 2019-03-26T10:03:19+00:00 gnzlbg gonzalobg88@gmail.com 2019-03-26T10:03:19+00:00 urn:sha1:6ea6e62075f21642bfd94b00bf641ea3fe4208c5 2019-03-10T03:49:45+00:00 John Kåre Alsaker john.kare.alsaker@gmail.com 2018-12-08T19:30:23+00:00 urn:sha1:51938c61f6f1b26e463f9071716f543543486e72 2019-01-03T21:52:36+00:00 Alex Crichton alex@alexcrichton.com 2019-01-02T21:23:45+00:00 urn:sha1:ccbf28eae8b345db3ede51112cc32c756a084bd9 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-26T04:08:33+00:00 Mark Rousskov mark.simulacrum@gmail.com 2018-12-25T15:56:47+00:00 urn:sha1:2a663555ddf36f6b041445894a8c175cd1bc718c 2018-12-19T16:27:23+00:00 Alex Crichton alex@alexcrichton.com 2018-12-19T16:27:23+00:00 urn:sha1:ba0ed5b13f23dd6e4ff0047a653ee615b84a67f2 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-12-12T05:08:22+00:00 Alex Crichton alex@alexcrichton.com 2018-11-20T05:52:50+00:00 urn:sha1:4c21a3bc2afc5933f31f1368f6b3406c5f1bdeb3 Ever since we added a Cargo-based build system for the compiler the standard library has always been a little special, it's never been able to depend on crates.io crates for runtime dependencies. This has been a result of various limitations, namely that Cargo doesn't understand that crates from crates.io depend on libcore, so Cargo tries to build crates before libcore is finished. I had an idea this afternoon, however, which lifts the strategy from #52919 to directly depend on crates.io crates from the standard library. After all is said and done this removes a whopping three submodules that we need to manage! The basic idea here is that for any crate `std` depends on it adds an *optional* dependency on an empty crate on crates.io, in this case named `rustc-std-workspace-core`. This crate is overridden via `[patch]` in this repository to point to a local crate we write, and *that* has a `path` dependency on libcore. Note that all `no_std` crates also depend on `compiler_builtins`, but if we're not using submodules we can publish `compiler_builtins` to crates.io and all crates can depend on it anyway! The basic strategy then looks like: * The standard library (or some transitive dep) decides to depend on a crate `foo`. * The standard library adds ```toml [dependencies] foo = { version = "0.1", features = ['rustc-dep-of-std'] } ``` * The crate `foo` has an optional dependency on `rustc-std-workspace-core` * The crate `foo` has an optional dependency on `compiler_builtins` * The crate `foo` has a feature `rustc-dep-of-std` which activates these crates and any other necessary infrastructure in the crate. A sample commit for `dlmalloc` [turns out to be quite simple][commit]. After that all `no_std` crates should largely build "as is" and still be publishable on crates.io! Notably they should be able to continue to use stable Rust if necessary, since the `rename-dependency` feature of Cargo is soon stabilizing. As a proof of concept, this commit removes the `dlmalloc`, `libcompiler_builtins`, and `libc` submodules from this repository. Long thorns in our side these are now gone for good and we can directly depend on crates.io! It's hoped that in the long term we can bring in other crates as necessary, but for now this is largely intended to simply make it easier to manage these crates and remove submodules. This should be a transparent non-breaking change for all users, but one possible stickler is that this almost for sure breaks out-of-tree `std`-building tools like `xargo` and `cargo-xbuild`. I think it should be relatively easy to get them working, however, as all that's needed is an entry in the `[patch]` section used to build the standard library. Hopefully we can work with these tools to solve this problem! [commit]: https://github.com/alexcrichton/dlmalloc-rs/commit/28ee12db813a3b650a7c25d1c36d2c17dcb88ae3 2018-12-07T05:56:50+00:00 Jethro Beekman jethro@fortanix.com 2018-08-28T04:33:26+00:00 urn:sha1:4a3505682e97c8e667338056ae216e4b84b22dd7 The files src/libstd/sys/sgx/*.rs are mostly copied/adapted from the wasm target. This also updates the dlmalloc submodule to the very latest version. 2018-12-02T12:27:12+00:00 Ralf Jung post@ralfj.de 2018-12-02T12:27:12+00:00 urn:sha1:d605e1d055dfd31b03e6e0da634928d4d5418866