1. 02 Apr, 2019 1 commit
  2. 31 Mar, 2019 1 commit
  3. 16 Mar, 2019 1 commit
    • Eric Huss's avatar
      CI: Set job names. · 20704146
      Eric Huss authored
      This should make it easier to identify what each job is doing when looking at the Travis or Appveyor UI.
      
      - Set `name` for each job in Travis.
      - Move `CI_JOB_NAME` to the front in Appveyor so that it appears first in the UI.
      20704146
  4. 01 Mar, 2019 2 commits
  5. 20 Feb, 2019 1 commit
  6. 06 Feb, 2019 1 commit
  7. 04 Feb, 2019 1 commit
  8. 14 Jan, 2019 1 commit
  9. 24 Nov, 2018 1 commit
  10. 13 Nov, 2018 2 commits
  11. 31 Oct, 2018 2 commits
  12. 24 Oct, 2018 1 commit
    • Alex Crichton's avatar
      ci: Move global credentials to web configuration · 3c25f80f
      Alex Crichton authored
      This commit moves a number of our encrypted credentials stored in
      configuration files in this repository to env vars on the web UI. This
      will hopefully make it easier to rotate credentials in the future as
      well as quickly change them if the need arises. (quicker than landing a
      PR that is).
      
      This also updates the travis deployment process to always use the `aws`
      command line tool which we're already installing on Linux and should
      enable us to avoid all `dpl` gem issues as well as have greater control
      over what's going where.
      3c25f80f
  13. 28 Sep, 2018 1 commit
  14. 14 May, 2018 1 commit
  15. 12 May, 2018 1 commit
  16. 11 May, 2018 1 commit
  17. 09 May, 2018 1 commit
    • Alex Crichton's avatar
      ci: Compile LLVM with Clang 6.0.0 · 7e5b9ac4
      Alex Crichton authored
      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.
      7e5b9ac4
  18. 05 Apr, 2018 1 commit
  19. 02 Apr, 2018 1 commit
    • Alex Crichton's avatar
      Update sccache to its master branch · 64f7e11f
      Alex Crichton authored
      Ideally I'd like to soon enable sccache for rustbuild itself and some of the
      stage0 tools, but for that to work we'll need some better Rust support than the
      pretty old version we were previously using!
      64f7e11f
  20. 24 Mar, 2018 1 commit
  21. 07 Mar, 2018 2 commits
  22. 04 Mar, 2018 1 commit
    • Alex Crichton's avatar
      rust: Import LLD for linking wasm objects · d69b2480
      Alex Crichton authored
      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
      d69b2480
  23. 23 Feb, 2018 1 commit
  24. 29 Jan, 2018 1 commit
    • Alex Crichton's avatar
      rustc: Split Emscripten to a separate codegen backend · c6daea7c
      Alex Crichton authored
      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
      c6daea7c
  25. 30 Dec, 2017 1 commit
  26. 26 Dec, 2017 1 commit
  27. 25 Dec, 2017 1 commit
  28. 06 Dec, 2017 1 commit
  29. 03 Dec, 2017 2 commits
  30. 23 Oct, 2017 1 commit
  31. 29 Sep, 2017 1 commit
  32. 17 Sep, 2017 1 commit
  33. 16 Sep, 2017 3 commits