1. 03 Apr, 2019 1 commit
  2. 29 Mar, 2019 1 commit
    • Alex Crichton's avatar
      Add a new wasm32-unknown-wasi target · ace71240
      Alex Crichton authored
      This commit adds a new wasm32-based target distributed through rustup,
      supported in the standard library, and implemented in the compiler. The
      `wasm32-unknown-wasi` target is intended to be a WebAssembly target
      which matches the [WASI proposal recently announced.][LINK]. In summary
      the WASI target is an effort to define a standard set of syscalls for
      WebAssembly modules, allowing WebAssembly modules to not only be
      portable across architectures but also be portable across environments
      implementing this standard set of system calls.
      The wasi target in libstd is still somewhat bare bones. This PR does not
      fill out the filesystem, networking, threads, etc. Instead it only
      provides the most basic of integration with the wasi syscalls, enabling
      features like:
      * `Instant::now` and `SystemTime::now` work
      * `env::args` is hooked up
      * `env::vars` will look up environment variables
      * `println!` will print to standard out
      * `process::{exit, abort}` should be hooked up appropriately
      None of these APIs can work natively on the `wasm32-unknown-unknown`
      target, but with the assumption of the WASI set of syscalls we're able
      to provide implementations of these syscalls that engines can implement.
      Currently the primary engine implementing wasi is [wasmtime], but more
      will surely emerge!
      In terms of future development of libstd, I think this is something
      we'll probably want to discuss. The purpose of the WASI target is to
      provide a standardized set of syscalls, but it's *also* to provide a
      standard C sysroot for compiling C/C++ programs. This means it's
      intended that functions like `read` and `write` are implemented for this
      target with a relatively standard definition and implementation. It's
      unclear, therefore, how we want to expose file descriptors and how we'll
      want to implement system primitives. For example should `std::fs::File`
      have a libc-based file descriptor underneath it? The raw wasi file
      descriptor? We'll see! Currently these details are all intentionally
      hidden and things we can change over time.
      A `WasiFd` sample struct was added to the standard library as part of
      this commit, but it's not currently used. It shows how all the wasi
      syscalls could be ergonomically bound in Rust, and they offer a possible
      implementation of primitives like `std::fs::File` if we bind wasi file
      descriptors exactly.
      Apart from the standard library, there's also the matter of how this
      target is integrated with respect to its C standard library. The
      reference sysroot, for example, provides managment of standard unix file
      descriptors and also standard APIs like `open` (as opposed to the
      relative `openat` inspiration for the wasi ssycalls). Currently the
      standard library relies on the C sysroot symbols for operations such as
      environment management, process exit, and `read`/`write` of stdio fds.
      We want these operations in Rust to be interoperable with C if they're
      used in the same process. Put another way, if Rust and C are linked into
      the same WebAssembly binary they should work together, but that requires
      that the same C standard library is used.
      We also, however, want the `wasm32-unknown-wasi` target to be
      usable-by-default with the Rust compiler without requiring a separate
      toolchain to get downloaded and configured. With that in mind, there's
      two modes of operation for the `wasm32-unknown-wasi` target:
      1. By default the C standard library is statically provided inside of
         `liblibc.rlib` distributed as part of the sysroot. This means that
         you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're
         good to go, a fully workable wasi binary pops out. This is
         incompatible with linking in C code, however, which may be compiled
         against a different sysroot than the Rust code was previously
         compiled against. In this mode the default of `rust-lld` is used to
         link binaries.
      2. For linking with C code, the `-C target-feature=-crt-static` flag
         needs to be passed. This takes inspiration from the musl target for
         this flag, but the idea is that you're no longer using the provided
         static C runtime, but rather one will be provided externally. This
         flag is intended to also get coupled with an external `clang`
         compiler configured with its own sysroot. Therefore you'll typically
         use this flag with `-C linker=/path/to/clang-script-wrapper`. Using
         this mode the Rust code will continue to reference standard C
         symbols, but the definition will be pulled in by the linker configured.
      Alright so that's all the current state of this PR. I suspect we'll
      definitely want to discuss this before landing of course! This PR is
      coupled with libc changes as well which I'll be posting shortly.
  3. 16 Mar, 2019 1 commit
  4. 05 Mar, 2019 1 commit
    • Hadley Canine's avatar
      Remove JSBackend from config.toml · c0cef334
      Hadley Canine authored
      JSBackend is implied when building the emscripten backend, and not available for the standard llvm backend.  This commit also puts the example config in sync with the defaults in src/bootstrap/native.rs
  5. 02 Mar, 2019 1 commit
    • Andy Russell's avatar
      look for python2 symlinks before bootstrap python · 12d8a7d6
      Andy Russell authored
      Before this commit, if you're running x.py directly on a system where
      `python` is symlinked to Python 3, then the `python` config option will
      default to a Python 3 interpreter. This causes debuginfo tests to fail
      with an opaque error message, since they have a hard requirement on
      Python 2.
      This commit modifies the Python probe behavior to look for python2.7 and
      python2 *before* using the interpreter used to execute `x.py`.
  6. 27 Feb, 2019 1 commit
  7. 30 Jan, 2019 1 commit
  8. 28 Jan, 2019 2 commits
  9. 14 Jan, 2019 1 commit
  10. 09 Jan, 2019 2 commits
  11. 06 Jan, 2019 1 commit
  12. 02 Jan, 2019 1 commit
  13. 30 Nov, 2018 1 commit
    • Alex Crichton's avatar
      ci: Only run compare-mode tests on one builder · 8ee62bb2
      Alex Crichton authored
      The run-pass test suite currently takes 30 minutes on Windows, and
      that appears to be roughly split between two 15 minute runs of the test
      suite: one without NLL and one with NLL. In discussion on Discord the
      platform coverage of the NLL compare mode may not necessarily be worth
      it, so this commit removes the NLL compare mode from tests by default,
      and then reenables it on only one builder.
  14. 02 Nov, 2018 2 commits
    • Alex Crichton's avatar
      Use `jemalloc-sys` on Linux and OSX compilers · 016eaf88
      Alex Crichton authored
      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
    • Alex Crichton's avatar
      Remove all jemalloc-related content · 61e89446
      Alex Crichton authored
      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.
  15. 26 Oct, 2018 1 commit
  16. 21 Oct, 2018 1 commit
    • Alex Crichton's avatar
      Update Cargo, build curl/OpenSSL statically via features · 4f661c01
      Alex Crichton authored
      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.
  17. 08 Oct, 2018 1 commit
  18. 01 Oct, 2018 1 commit
  19. 25 Sep, 2018 1 commit
    • Tom Tromey's avatar
      Improvements to finding LLVM's FileCheck · f4b4939f
      Tom Tromey authored
      This patch adds a few improvements to how the build system finds
      LLVM's FileCheck program.
      * On Fedora, the system LLVM installs FileCheck in the "llvm"
        subdirectory of the LLVM libdir.  This patch teaches the build
        system to look there.
      * This adds a configure option to specify which llvm-config executable
        to use.  This is handy on systems that can parallel install multiple
        versions of LLVM; for example I can now:
          ./configure --llvm-config=/bin/llvm-config-5.0-64
        ... to build against LLVM 5, rather than whatever the default
        llvm-config might be.
      * Finally, this adds a configure- and config.toml- option to set the
        path to FileCheck.  This is handy when building against an LLVM
        where FileCheck was not installed.  This happens on compatibility
        installs of LLVM on Fedora.
  20. 10 Sep, 2018 1 commit
    • Alex Crichton's avatar
      Add rustc SHA to released DWARF debuginfo · 5595aeb6
      Alex Crichton authored
      This commit updates the debuginfo that is encoded in all of our released
      artifacts by default. Currently it has paths like `/checkout/src/...` but these
      are a little inconsistent and have changed over time. This commit instead
      attempts to actually define the file paths in our debuginfo to be consistent
      between releases.
      All debuginfo paths are now intended to be `/rustc/$sha` where `$sha` is the git
      sha of the released compiler. Sub-paths are all paths into the git repo at that
  21. 07 Sep, 2018 1 commit
  22. 20 Aug, 2018 2 commits
  23. 15 Aug, 2018 1 commit
    • Tom Tromey's avatar
      Add lldb to the build · 6e3a4f4d
      Tom Tromey authored
      This optionally adds lldb (and clang, which it needs) to the build.
      Because rust uses LLVM 7, and because clang 7 is not yet released, a
      recent git master version of clang is used.
      The lldb that is used includes the Rust plugin.
      lldb is only built when asked for, or when doing a nightly build on
      macOS.  Only macOS is done for now due to difficulties with the Python
  24. 01 Aug, 2018 2 commits
  25. 07 Jul, 2018 5 commits
  26. 12 Jun, 2018 1 commit
  27. 07 Jun, 2018 1 commit
  28. 05 Jun, 2018 1 commit
  29. 03 Jun, 2018 1 commit
  30. 02 Jun, 2018 1 commit
  31. 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.