https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.40.0 2018-11-14T16:42:06+00:00 2018-11-14T16:42:06+00:00 Michael Woerister michaelwoerister@posteo 2018-11-14T16:41:54+00:00 urn:sha1:2ec6f340cd29f289fea1c5a672195ceeaf44c475 2018-11-02T13:52:56+00:00 Alex Crichton alex@alexcrichton.com 2018-10-21T02:15:06+00:00 urn:sha1:016eaf88f5bca6c9253eedec713c6ddcd6da2906 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-10-21T01:47:01+00:00 Alex Crichton alex@alexcrichton.com 2018-10-08T17:39:09+00:00 urn:sha1:4f661c016fe5cb015df1ba26baa9bafb76f51769 In addition to to updating Cargo's submodule and Cargo's dependencies, this also updates Cargo's build to build OpenSSL statically into Cargo as well as libcurl unconditionally. This removes OpenSSL build logic from the bootstrap code, and otherwise requests that even on OSX we build curl statically. 2018-09-28T13:55:18+00:00 Christian Poveda christianpoveda@protonmail.com 2018-09-28T07:07:44+00:00 urn:sha1:0724ed68bb0c6c5be89753f1da13ea27dfe2301d 2018-05-09T21:45:34+00:00 Alex Crichton alex@alexcrichton.com 2018-04-24T15:34:14+00:00 urn:sha1:7e5b9ac41e36b29d5208f4e5455aade07d4d107d Currently on CI we predominately compile LLVM with the default system compiler which means gcc on Linux, some version of Clang on OSX, MSVC on Windows, and gcc on MinGW. This commit switches Linux, OSX, and Windows to all use Clang 6.0.0 to build LLVM (aka the C/C++ compiler as part of the bootstrap). This looks to generate faster code according to #49879 which translates to a faster rustc (as LLVM internally is faster) The major changes here were to the containers that build Linux releases, basically adding a new step that uses the previous gcc 4.8 compiler to compile the next Clang 6.0.0 compiler. Otherwise the OSX and Windows scripts have been updated to download precompiled versions of Clang 6 and configure the build to use them. Note that `cc` was updated here to fix using `clang-cl` with `cc-rs` on MSVC, as well as an update to `sccache` on Windows which was needed to correctly work with `clang-cl`. Finally the MinGW compiler is entirely left out here intentionally as it's currently thought that Clang can't generate C++ code for MinGW and we need to use gcc, but this should be verified eventually. 2018-03-04T04:21:35+00:00 Alex Crichton alex@alexcrichton.com 2017-08-27T01:30:12+00:00 urn:sha1:d69b24805b5071e5ec9e62d2777a761723644144 This commit imports the LLD project from LLVM to serve as the default linker for the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently removed along with "binaryen linker" support in rustc. Moving to LLD brings with it a number of benefits for wasm code: * LLD is itself an actual linker, so there's no need to compile all wasm code with LTO any more. As a result builds should be *much* speedier as LTO is no longer forcibly enabled for all builds of the wasm target. * LLD is quickly becoming an "official solution" for linking wasm code together. This, I believe at least, is intended to be the main supported linker for native code and wasm moving forward. Picking up support early on should help ensure that we can help LLD identify bugs and otherwise prove that it works great for all our use cases! * Improvements to the wasm toolchain are currently primarily focused around LLVM and LLD (from what I can tell at least), so it's in general much better to be on this bandwagon for bugfixes and new features. * Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which means a postprocessor is no longer needed to show off Rust's "small wasm binary size". LLD is added in a pretty standard way to rustc right now. A new rustbuild target was defined for building LLD, and this is executed when a compiler's sysroot is being assembled. LLD is compiled against the LLVM that we've got in tree, which means we're currently on the `release_60` branch, but this may get upgraded in the near future! LLD is placed into rustc's sysroot in a `bin` directory. This is similar to where `gcc.exe` can be found on Windows. This directory is automatically added to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd` linker which implements the interface that `wasm-ld`, LLD's frontend, expects. Like Emscripten the LLD target is currently only enabled for Tier 1 platforms, notably OSX/Windows/Linux, and will need to be installed manually for compiling to wasm on other platforms. LLD is by default turned off in rustbuild, and requires a `config.toml` option to be enabled to turn it on. Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD has a native option for controlling this. [gc]: https://reviews.llvm.org/D42511 2018-03-02T18:28:29+00:00 Mark Simulacrum mark.simulacrum@gmail.com 2018-02-11T22:52:44+00:00 urn:sha1:ab7ce1c3c48d4f1be6c16928704e2eec0aed9ae2 These arguments are passed to the relevant x.py invocation in all cases anyway. As such, there is no need to separately configure them. x.py will ignore the configuration when they are passed on the command line anyway. 2018-02-09T18:12:32+00:00 Alex Crichton alex@alexcrichton.com 2018-02-09T18:12:32+00:00 urn:sha1:9c05babe25bd25db423c7f83c31de000ee4d4db7 Right now the `--build` option was accidentally omitted, so we're bootstraping from `x86_64` to `i686`. In addition to being slower (more compiles) that's not actually bootstrapping! 2018-01-29T02:32:45+00:00 Alex Crichton alex@alexcrichton.com 2018-01-24T16:22:34+00:00 urn:sha1:c6daea7c9a7d4be88e1ae8d54d992937fcfe24fa This commit introduces a separately compiled backend for Emscripten, avoiding compiling the `JSBackend` target in the main LLVM codegen backend. This builds on the foundation provided by #47671 to create a new codegen backend dedicated solely to Emscripten, removing the `JSBackend` of the main codegen backend in the process. A new field was added to each target for this commit which specifies the backend to use for translation, the default being `llvm` which is the main backend that we use. The Emscripten targets specify an `emscripten` backend instead of the main `llvm` one. There's a whole bunch of consequences of this change, but I'll try to enumerate them here: * A *second* LLVM submodule was added in this commit. The main LLVM submodule will soon start to drift from the Emscripten submodule, but currently they're both at the same revision. * Logic was added to rustbuild to *not* build the Emscripten backend by default. This is gated behind a `--enable-emscripten` flag to the configure script. By default users should neither check out the emscripten submodule nor compile it. * The `init_repo.sh` script was updated to fetch the Emscripten submodule from GitHub the same way we do the main LLVM submodule (a tarball fetch). * The Emscripten backend, turned off by default, is still turned on for a number of targets on CI. We'll only be shipping an Emscripten backend with Tier 1 platforms, though. All cross-compiled platforms will not be receiving an Emscripten backend yet. This commit means that when you download the `rustc` package in Rustup for Tier 1 platforms you'll be receiving two trans backends, one for Emscripten and one that's the general LLVM backend. If you never compile for Emscripten you'll never use the Emscripten backend, so we may update this one day to only download the Emscripten backend when you add the Emscripten target. For now though it's just an extra 10MB gzip'd. Closes #46819 2017-08-27T01:34:13+00:00 Alex Crichton alex@alexcrichton.com 2017-08-27T01:34:13+00:00 urn:sha1:ffe64a26abb194a7ddcc5f410512043a65b3eb91 Newer versions of Docker have a `--init` argument which spawns an init process in the container, which we should be able to use everywhere now.