OpenE2K/rust
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
becee90cfd
rust/Cargo.lock

4343 lines
190 KiB
Plaintext
Raw Normal View History

Add Cargo.lock automatically adding message
2019-02-04 17:31:48 +01:00
# This file is automatically @generated by Cargo.
# It is not intended for manual editing.
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
[[package]]
name = "adler32"
version = "1.0.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
[[package]]
name = "aho-corasick"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "0.6.9"
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"memchr 2.1.1 (registry+https://github.com/rust-lang/crates.io-index)",
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
]
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
[[package]]
name = "alloc"
version = "0.0.0"
dependencies = [
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"compiler_builtins 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"core 0.0.0",
std: Depend directly on crates.io crates 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-11-20 06:52:50 +01:00
"rand 0.6.1 (registry+https://github.com/rust-lang/crates.io-index)",
fix deprecation warnings in liballoc benches
2018-12-21 11:33:29 +01:00
"rand_xorshift 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
]
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
[[package]]
name = "ammonia"
version = "1.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Reduce the numbers of syn versions compiled from 4 to 2 The last remaining one comes from mdbook. Unfortunately updating it breaks everything
2018-12-08 15:11:47 +01:00
"html5ever 0.22.5 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS
2018-12-10 08:58:08 +01:00
"lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
"maplit 1.0.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"matches 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)",
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
"tendril 0.4.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"url 1.7.2 (registry+https://github.com/rust-lang/crates.io-index)",
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
]
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
[[package]]
name = "ansi_term"
Update Cargo This notably includes * https://github.com/rust-lang/cargo/pull/5152 * https://github.com/rust-lang/cargo/pull/5188 The first one switches cargo from docopt to clap ( we also update to the latest calp in this repository), the second one should help us to unify feature flags for Cargo itself and RLS, and build Cargo libray only once.
2018-03-16 11:37:14 +01:00
version = "0.11.0"
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Update Cargo This notably includes * https://github.com/rust-lang/cargo/pull/5152 * https://github.com/rust-lang/cargo/pull/5188 The first one switches cargo from docopt to clap ( we also update to the latest calp in this repository), the second one should help us to unify feature flags for Cargo itself and RLS, and build Cargo libray only once.
2018-03-16 11:37:14 +01:00
dependencies = [
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo This notably includes * https://github.com/rust-lang/cargo/pull/5152 * https://github.com/rust-lang/cargo/pull/5188 The first one switches cargo from docopt to clap ( we also update to the latest calp in this repository), the second one should help us to unify feature flags for Cargo itself and RLS, and build Cargo libray only once.
2018-03-16 11:37:14 +01:00
]
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
[[package]]
name = "arc-swap"
version = "0.3.7"
source = "registry+https://github.com/rust-lang/crates.io-index"
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
[[package]]
name = "arena"
version = "0.0.0"
Make arenas thread safe
2017-12-03 13:49:46 +01:00
dependencies = [
"rustc_data_structures 0.0.0",
]
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
Update Cargo.lock
2019-02-18 10:32:58 +01:00
[[package]]
name = "argon2rs"
version = "0.2.5"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"blake2-rfc 0.2.18 (registry+https://github.com/rust-lang/crates.io-index)",
"scoped_threadpool 0.1.9 (registry+https://github.com/rust-lang/crates.io-index)",
]
Update to newer version of mdbook(2)
2019-01-19 03:39:37 +01:00
[[package]]
name = "arrayref"
version = "0.3.5"
source = "registry+https://github.com/rust-lang/crates.io-index"
Update RLS
2018-02-26 04:15:45 +01:00
[[package]]
name = "arrayvec"
version = "0.4.7"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"nodrop 0.1.12 (registry+https://github.com/rust-lang/crates.io-index)",
]
Update cargo/rls submodules and dependencies Brings in a few regression fixes on the Cargo side, updates the rls to work with the newer Cargo, and also updates other crates.io dependencies to pull in various bug fixes and such.
2017-06-15 04:33:06 +02:00
[[package]]
name = "atty"
revert accidental atty downgrade
2018-07-27 15:10:52 +02:00
version = "0.2.11"
Update cargo/rls submodules and dependencies Brings in a few regression fixes on the Cargo side, updates the rls to work with the newer Cargo, and also updates other crates.io dependencies to pull in various bug fixes and such.
2017-06-15 04:33:06 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
"termion 1.5.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo/rls submodules and dependencies Brings in a few regression fixes on the Cargo side, updates the rls to work with the newer Cargo, and also updates other crates.io dependencies to pull in various bug fixes and such.
2017-06-15 04:33:06 +02:00
]
Update to the oxidized rust-installer
2017-05-09 00:01:13 +02:00
[[package]]
name = "backtrace"
bump backtrace version to get prettier pretty-printing
2018-12-11 22:36:24 +01:00
version = "0.3.11"
Update to the oxidized rust-installer
2017-05-09 00:01:13 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
std: Use backtrace-sys from crates.io This commit switches the standard library to using the `backtrace-sys` crate from crates.io instead of duplicating the logic here in the Rust repositor with the `backtrace-sys`'s crate's logic. Eventually this will hopefully be a good step towards using the `backtrace` crate directly from crates.io itself, but we're not quite there yet! Hopefully this is a small incremental first step we can take.
2018-12-15 01:47:18 +01:00
"backtrace-sys 0.1.27 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"cfg-if 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
std: Use `rustc_demangle` from crates.io No more need to duplicate the demangling routine between crates.io and the standard library, we can use the exact same one!
2018-12-14 23:37:51 +01:00
"rustc-demangle 0.1.10 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update to the oxidized rust-installer
2017-05-09 00:01:13 +02:00
]
[[package]]
name = "backtrace-sys"
std: Use backtrace-sys from crates.io This commit switches the standard library to using the `backtrace-sys` crate from crates.io instead of duplicating the logic here in the Rust repositor with the `backtrace-sys`'s crate's logic. Eventually this will hopefully be a good step towards using the `backtrace` crate directly from crates.io itself, but we're not quite there yet! Hopefully this is a small incremental first step we can take.
2018-12-15 01:47:18 +01:00
version = "0.1.27"
Update to the oxidized rust-installer
2017-05-09 00:01:13 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update cc crate to include Armv8-M changes
2019-01-09 15:51:22 +01:00
"cc 1.0.28 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"compiler_builtins 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)",
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
std: Use backtrace-sys from crates.io This commit switches the standard library to using the `backtrace-sys` crate from crates.io instead of duplicating the logic here in the Rust repositor with the `backtrace-sys`'s crate's logic. Eventually this will hopefully be a good step towards using the `backtrace` crate directly from crates.io itself, but we're not quite there yet! Hopefully this is a small incremental first step we can take.
2018-12-15 01:47:18 +01:00
"rustc-std-workspace-core 1.0.0",
Update to the oxidized rust-installer
2017-05-09 00:01:13 +02:00
]
Update Cargo's submodule Bring in a few updates and fixes, mostly a standard update.
2018-09-28 20:27:30 +02:00
[[package]]
name = "bit-set"
version = "0.5.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"bit-vec 0.5.0 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "bit-vec"
version = "0.5.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
update git2 Fixes build with libressl Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
2017-06-07 21:42:17 +02:00
[[package]]
name = "bitflags"
version = "0.9.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
Remove rustc_bitflags; use the bitflags crate
2017-09-08 21:08:01 +02:00
[[package]]
name = "bitflags"
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
version = "1.0.4"
Remove rustc_bitflags; use the bitflags crate
2017-09-08 21:08:01 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Update Cargo.lock
2019-02-18 10:32:58 +01:00
[[package]]
name = "blake2-rfc"
version = "0.2.18"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"arrayvec 0.4.7 (registry+https://github.com/rust-lang/crates.io-index)",
"constant_time_eq 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)",
]
Update to newer version of mdbook(2)
2019-01-19 03:39:37 +01:00
[[package]]
name = "block-buffer"
version = "0.3.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"arrayref 0.3.5 (registry+https://github.com/rust-lang/crates.io-index)",
"byte-tools 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
]
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
[[package]]
name = "bootstrap"
version = "0.0.0"
dependencies = [
"build_helper 0.1.0",
lock after rebase
2019-01-17 11:22:48 +01:00
"cc 1.0.28 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"cmake 0.1.33 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"filetime 0.2.4 (registry+https://github.com/rust-lang/crates.io-index)",
Bump to 1.27.0 Also update some `Cargo.lock` dependencies, finishing up some final steps of our [release process]! This doesn't update the bootstrap compiler just yet but that will come in a follow-up PR. [release process]: https://forge.rust-lang.org/release-process.html
2018-04-02 17:43:55 +02:00
"getopts 0.2.17 (registry+https://github.com/rust-lang/crates.io-index)",
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
"lazy_static 0.2.11 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo and its dependencies This'll probably have a bunch of build errors, so let's try and head those off and find them sooner rather than later!
2018-01-08 22:56:22 +01:00
"num_cpus 1.8.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update `petgraph` dependency to 0.4.13 This fixes building `bootstrap` using a local Rust nightly.
2018-09-08 08:04:29 +02:00
"petgraph 0.4.13 (registry+https://github.com/rust-lang/crates.io-index)",
Add tests to rustbuild In order to run tests, previous commits have cfg'd out various parts of rustbuild. Generally speaking, these are filesystem-related operations and process-spawning related parts. Then, rustbuild is run "as normal" and the various steps that where run are retrieved from the cache and checked against the expected results. Note that this means that the current implementation primarily tests "what" we build, but doesn't actually test that what we build *will* build. In other words, it doesn't do any form of dependency verification for any crate. This is possible to implement, but is considered future work. This implementation strives to cfg out as little code as possible; it also does not currently test anywhere near all of rustbuild. The current tests are also not checked for "correctness," rather, they simply represent what we do as of this commit, which may be wrong. Test cases are drawn from the old implementation of rustbuild, though the expected results may vary.
2018-03-10 15:03:06 +01:00
"pretty_assertions 0.5.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo, rls, miri
2018-12-17 19:23:04 +01:00
"serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"serde_derive 1.0.81 (registry+https://github.com/rust-lang/crates.io-index)",
"serde_json 1.0.33 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"time 0.1.40 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"toml 0.4.10 (registry+https://github.com/rust-lang/crates.io-index)",
rustbuild: Add manifest generation in-tree This commit adds a new tool, `build-manifest`, which is used to generate a distribution manifest of all produced artifacts. This tool is intended to replace the `build-rust-manifest.py` script that's currently located on the buildmaster. The intention is that we'll have a builder which periodically: * Downloads all artifacts for a commit * Runs `./x.py dist hash-and-sign`. This will generate `sha256` and `asc` files as well as TOML manifests. * Upload all generated hashes and manifests to the directory the artifacts came from. * Upload *all* artifacts (tarballs and hashes and manifests) to an archived location. * If necessary, upload all artifacts to the main location. This script is intended to just be the second step here where orchestrating uploads and such will all happen externally from the build system itself.
2017-01-24 23:37:04 +01:00
]
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
[[package]]
name = "bufstream"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "0.1.4"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
rustbuild: Add manifest generation in-tree This commit adds a new tool, `build-manifest`, which is used to generate a distribution manifest of all produced artifacts. This tool is intended to replace the `build-rust-manifest.py` script that's currently located on the buildmaster. The intention is that we'll have a builder which periodically: * Downloads all artifacts for a commit * Runs `./x.py dist hash-and-sign`. This will generate `sha256` and `asc` files as well as TOML manifests. * Upload all generated hashes and manifests to the directory the artifacts came from. * Upload *all* artifacts (tarballs and hashes and manifests) to an archived location. * If necessary, upload all artifacts to the main location. This script is intended to just be the second step here where orchestrating uploads and such will all happen externally from the build system itself.
2017-01-24 23:37:04 +01:00
[[package]]
name = "build-manifest"
version = "0.1.0"
dependencies = [
Update cargo, rls, miri
2018-12-17 19:23:04 +01:00
"serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"serde_derive 1.0.81 (registry+https://github.com/rust-lang/crates.io-index)",
"toml 0.4.10 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
]
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
[[package]]
name = "build_const"
version = "0.2.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
[[package]]
name = "build_helper"
version = "0.1.0"
Update to newer version of mdbook(2)
2019-01-19 03:39:37 +01:00
[[package]]
name = "byte-tools"
version = "0.2.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
[[package]]
name = "bytecount"
Update Cargo.lock
2019-02-18 10:32:58 +01:00
version = "0.5.1"
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update RLS and Rustfmt Closes #56261
2018-12-01 11:36:32 +01:00
"packed_simd 0.3.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
]
Adjust imports to librustc::mir::interpret
2017-09-18 16:18:23 +02:00
[[package]]
name = "byteorder"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "1.2.7"
Adjust imports to librustc::mir::interpret
2017-09-18 16:18:23 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
[[package]]
name = "bytes"
version = "0.4.11"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"byteorder 1.2.7 (registry+https://github.com/rust-lang/crates.io-index)",
"iovec 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)",
]
Update Cargo This commit brings in a few Cargo updates * Updates Cargo with experimental HTTP/2 support - a post on the forums will be made about testing this when available. * Bumps Cargo's own version number
2018-09-20 23:37:53 +02:00
[[package]]
name = "bytesize"
version = "1.0.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
[[package]]
name = "cargo"
Update cargo, rls
2019-03-04 22:18:44 +01:00
version = "0.36.0"
Point RLS submodule at a branch with required changes And cargo update
2017-07-19 03:32:12 +02:00
dependencies = [
revert accidental atty downgrade
2018-07-27 15:10:52 +02:00
"atty 0.2.11 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"bufstream 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock
2019-01-10 13:42:14 +01:00
"byteorder 1.2.7 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo This commit brings in a few Cargo updates * Updates Cargo with experimental HTTP/2 support - a post on the forums will be made about testing this when available. * Bumps Cargo's own version number
2018-09-20 23:37:53 +02:00
"bytesize 1.0.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"clap 2.32.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"core-foundation 0.6.3 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo, rls
2019-03-04 22:18:44 +01:00
"crates-io 0.24.0",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"crossbeam-utils 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Required moving all fulldeps tests depending on `rand` to different locations as now there's multiple `rand` crates that can't be implicitly linked against.
2018-02-26 18:07:16 +01:00
"crypto-hash 0.3.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Hopefully a relatively routine update!
2018-11-09 21:55:25 +01:00
"curl 0.4.19 (registry+https://github.com/rust-lang/crates.io-index)",
"curl-sys 0.4.15 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Brings in some fixes and stabilizations!
2018-11-16 12:08:23 +01:00
"env_logger 0.6.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo
2019-02-03 23:42:29 +01:00
"failure 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"filetime 0.2.4 (registry+https://github.com/rust-lang/crates.io-index)",
"flate2 1.0.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo and its dependencies This'll probably have a bunch of build errors, so let's try and head those off and find them sooner rather than later!
2018-01-08 22:56:22 +01:00
"fs2 0.4.3 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo
2018-08-14 23:27:26 +02:00
"fwdansi 1.0.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock
2019-01-10 13:42:14 +01:00
"git2 0.8.0 (registry+https://github.com/rust-lang/crates.io-index)",
"git2-curl 0.9.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo
2019-03-12 21:34:47 +01:00
"glob 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"hex 0.3.2 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"home 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)",
Update parking_lot to 0.7 Unfortunately this'll dupe parking_lot until the data_structures crate is published and be updated in rls in conjunction with crossbeam-channel
2019-02-22 13:49:19 +01:00
"ignore 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock
2019-02-18 10:32:58 +01:00
"im-rc 12.3.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo
2019-03-29 04:13:13 +01:00
"jobserver 0.1.13 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS
2018-12-10 08:58:08 +01:00
"lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"lazycell 1.2.1 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo, rls, miri
2018-12-17 19:23:04 +01:00
"libgit2-sys 0.7.11 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"miow 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo and its dependencies This'll probably have a bunch of build errors, so let's try and head those off and find them sooner rather than later!
2018-01-08 22:56:22 +01:00
"num_cpus 1.8.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"opener 0.3.2 (registry+https://github.com/rust-lang/crates.io-index)",
Upgrade openssl and openssl-sys
2019-01-02 11:06:36 +01:00
"openssl 0.10.16 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"pretty_env_logger 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo
2019-03-29 04:13:13 +01:00
"proptest 0.9.2 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Bring in some fixes for `cargo fix` notably
2018-07-31 23:16:55 +02:00
"rustc-workspace-hack 1.0.0",
Update cargo, rls, miri
2018-12-17 19:23:04 +01:00
"rustfix 0.4.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"same-file 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo and its dependencies This'll probably have a bunch of build errors, so let's try and head those off and find them sooner rather than later!
2018-01-08 22:56:22 +01:00
"semver 0.9.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo, rls, miri
2018-12-17 19:23:04 +01:00
"serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)",
rustbuild: Switch back to using hard links The `copy` function historically in rustbuild used hard links to speed up the copy operations that it does. This logic was backed out, however, in #39518 due to a bug that only showed up on Windows, described in #39504. The cause described in #39504 happened because Cargo, on a fresh build, would overwrite the previous artifacts with new hard links that Cargo itself manages. This behavior in Cargo was fixed in rust-lang/cargo#4390 where it no longer should overwrite files on fresh builds, opportunistically leaving the filesystem intact and not touching it. Hopefully this can help speed up local builds by doing fewer copies all over the place!
2017-09-02 05:46:51 +02:00
"serde_ignored 0.0.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"serde_json 1.0.33 (registry+https://github.com/rust-lang/crates.io-index)",
Bump to 1.27.0 Also update some `Cargo.lock` dependencies, finishing up some final steps of our [release process]! This doesn't update the bootstrap compiler just yet but that will come in a follow-up PR. [release process]: https://forge.rust-lang.org/release-process.html
2018-04-02 17:43:55 +02:00
"shell-escape 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"tar 0.4.20 (registry+https://github.com/rust-lang/crates.io-index)",
"tempfile 3.0.5 (registry+https://github.com/rust-lang/crates.io-index)",
"termcolor 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo
2019-03-29 04:13:13 +01:00
"toml 0.5.0 (registry+https://github.com/rust-lang/crates.io-index)",
Bootstrap from 1.28.0-beta.3
2018-06-22 17:48:43 +02:00
"unicode-width 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"url 1.7.2 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock
2019-01-10 13:42:14 +01:00
"url_serde 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo
2019-03-29 04:13:13 +01:00
"walkdir 2.2.7 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
]
update miri
2018-07-13 10:34:50 +02:00
[[package]]
name = "cargo_metadata"
submodules: update clippy from d8b42690 to f5d868c9 Fixes clippy toolstate. Changes: ```` rustup https://github.com/rust-lang/rust/pull/55852/ Fix "too" -> "foo" typo in format.rs Fix `use_self` violation Fix wrong suggestion for `redundant_closure_call` Check for common metadata Fix `use_self` false positive on `use` statements Fix `use_self` false positive Remove `+` from `has_unary_equivalent` Fix dogfood Update println! formatting Fix false positive in check mode caused by `gen_deprecated` RIIR update lints: Add check mode (update_lints.py rewrite complete) changed into_iter to iter and fixed a lint check Fix `collapsible_if` error Fix `possible_missing_comma` false positives format code fix comment spacing change single char str to char add lint to lintarray macro Revert "small fix" small fix added float support for mistyped literal lints tmp progress ````
2018-11-14 14:49:40 +01:00
version = "0.6.2"
update miri
2018-07-13 10:34:50 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"error-chain 0.12.0 (registry+https://github.com/rust-lang/crates.io-index)",
"semver 0.9.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo, rls, miri
2018-12-17 19:23:04 +01:00
"serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"serde_derive 1.0.81 (registry+https://github.com/rust-lang/crates.io-index)",
"serde_json 1.0.33 (registry+https://github.com/rust-lang/crates.io-index)",
update miri
2018-07-13 10:34:50 +02:00
]
submodules: update clippy from f1753522 to 6ce78d12 Changes: ```` wildcard_match_arm: Update lint count. wildcard_match_arm: add nesting issue to known. wildcard_match_arm: lint only enum matches. wildcard_match_arm: update ui test stderr wildcard_match_arm: format test. wilcard_match_arm: run rustfmt. wildcard_match_arm: add lint properly. wildcard_match_arm: rename function. wildcard_match_arm: add simple ui test. wildcard_match_arm: expand lint scope. Change match_wild lint name to WILDCARD_MATCH_ARM. Add match_wild lint (#3649). fetch_prs_between: add .sh file ending cargo fmt Update various docs Use built-in entry_fn detection over self-built cargo fmt Reorganize conditionals: Run faster checks first Maybe fix ICE? Add initial version of const_fn lint Fix `unit_arg` false positive Rustfmt Check hypothetically failing conversion Remove tests for deprecated items Update more changed iterator paths Atomics constants are now handled by the deprecation lint Update changed iterator paths Update const slice processing update test stderr run cargo fmt rustup https://github.com/rust-lang/rust/pull/57907/ Fix documentation for `slow_vector_initialization` rustup https://github.com/rust-lang/rust/pull/57726 Remove unsafe_vector_initialization from added lints Prevent incorrect cast_lossless suggestion in const_fn Incorporate review suggestions Fix dogfood tests on Appveyor test(versioncheck): Use .no_deps() test(versioncheck): Fix version equality check chore(cargo/dependencies/cargo-metadata): Upgrade to 0.7.1 dependencies: update itertools from 0.7 to 0.8 Add script to fetch GitHub PRs between two commits gitattributes: Treat .fixed files as rust files Update changelog with all changes since 0.0.212 Fix `expect_fun_call` lint suggestions ````
2019-01-30 01:24:37 +01:00
[[package]]
name = "cargo_metadata"
version = "0.7.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"error-chain 0.12.0 (registry+https://github.com/rust-lang/crates.io-index)",
"semver 0.9.0 (registry+https://github.com/rust-lang/crates.io-index)",
"serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)",
"serde_derive 1.0.81 (registry+https://github.com/rust-lang/crates.io-index)",
"serde_json 1.0.33 (registry+https://github.com/rust-lang/crates.io-index)",
]
Add Cargo as a submodule
2017-02-15 23:55:26 +01:00
[[package]]
name = "cargotest2"
version = "0.1.0"
Update RLS and Rustfmt
2017-09-22 03:58:35 +02:00
[[package]]
name = "cc"
Update cc crate to include Armv8-M changes
2019-01-09 15:51:22 +01:00
version = "1.0.28"
Update RLS and Rustfmt
2017-09-22 03:58:35 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Update to the oxidized rust-installer
2017-05-09 00:01:13 +02:00
[[package]]
name = "cfg-if"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "0.1.6"
Update to the oxidized rust-installer
2017-05-09 00:01:13 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
get `rustc_hash` from external crate
2018-05-24 14:48:02 +02:00
[[package]]
name = "chalk-engine"
Handle sub-typing in chalk-engine
2018-11-28 22:11:00 +01:00
version = "0.9.0"
get `rustc_hash` from external crate
2018-05-24 14:48:02 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"chalk-macros 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update rustc-hash to hash up to 8 bytes at once with FxHasher
2018-05-24 05:37:40 +02:00
"rustc-hash 1.0.1 (registry+https://github.com/rust-lang/crates.io-index)",
get `rustc_hash` from external crate
2018-05-24 14:48:02 +02:00
]
[[package]]
name = "chalk-macros"
version = "0.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"lazy_static 0.2.11 (registry+https://github.com/rust-lang/crates.io-index)",
]
Update Cargo submodule to master Just a routine update
2018-01-25 05:01:42 +01:00
[[package]]
name = "chrono"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "0.4.6"
Update Cargo submodule to master Just a routine update
2018-01-25 05:01:42 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"num-integer 0.1.39 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"num-traits 0.2.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"time 0.1.40 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule to master Just a routine update
2018-01-25 05:01:42 +01:00
]
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
[[package]]
name = "clap"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
version = "2.32.0"
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo This notably includes * https://github.com/rust-lang/cargo/pull/5152 * https://github.com/rust-lang/cargo/pull/5188 The first one switches cargo from docopt to clap ( we also update to the latest calp in this repository), the second one should help us to unify feature flags for Cargo itself and RLS, and build Cargo libray only once.
2018-03-16 11:37:14 +01:00
"ansi_term 0.11.0 (registry+https://github.com/rust-lang/crates.io-index)",
revert accidental atty downgrade
2018-07-27 15:10:52 +02:00
"atty 0.2.11 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"bitflags 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo This notably includes * https://github.com/rust-lang/cargo/pull/5152 * https://github.com/rust-lang/cargo/pull/5188 The first one switches cargo from docopt to clap ( we also update to the latest calp in this repository), the second one should help us to unify feature flags for Cargo itself and RLS, and build Cargo libray only once.
2018-03-16 11:37:14 +01:00
"strsim 0.7.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"textwrap 0.10.0 (registry+https://github.com/rust-lang/crates.io-index)",
Bootstrap from 1.28.0-beta.3
2018-06-22 17:48:43 +02:00
"unicode-width 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"vec_map 0.8.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update to the oxidized rust-installer
2017-05-09 00:01:13 +02:00
"yaml-rust 0.3.5 (registry+https://github.com/rust-lang/crates.io-index)",
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
]
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
[[package]]
name = "clippy"
Update clippy and rls
2018-07-15 00:01:24 +02:00
version = "0.0.212"
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
dependencies = [
submodules: update clippy from f1753522 to 6ce78d12 Changes: ```` wildcard_match_arm: Update lint count. wildcard_match_arm: add nesting issue to known. wildcard_match_arm: lint only enum matches. wildcard_match_arm: update ui test stderr wildcard_match_arm: format test. wilcard_match_arm: run rustfmt. wildcard_match_arm: add lint properly. wildcard_match_arm: rename function. wildcard_match_arm: add simple ui test. wildcard_match_arm: expand lint scope. Change match_wild lint name to WILDCARD_MATCH_ARM. Add match_wild lint (#3649). fetch_prs_between: add .sh file ending cargo fmt Update various docs Use built-in entry_fn detection over self-built cargo fmt Reorganize conditionals: Run faster checks first Maybe fix ICE? Add initial version of const_fn lint Fix `unit_arg` false positive Rustfmt Check hypothetically failing conversion Remove tests for deprecated items Update more changed iterator paths Atomics constants are now handled by the deprecation lint Update changed iterator paths Update const slice processing update test stderr run cargo fmt rustup https://github.com/rust-lang/rust/pull/57907/ Fix documentation for `slow_vector_initialization` rustup https://github.com/rust-lang/rust/pull/57726 Remove unsafe_vector_initialization from added lints Prevent incorrect cast_lossless suggestion in const_fn Incorporate review suggestions Fix dogfood tests on Appveyor test(versioncheck): Use .no_deps() test(versioncheck): Fix version equality check chore(cargo/dependencies/cargo-metadata): Upgrade to 0.7.1 dependencies: update itertools from 0.7 to 0.8 Add script to fetch GitHub PRs between two commits gitattributes: Treat .fixed files as rust files Update changelog with all changes since 0.0.212 Fix `expect_fun_call` lint suggestions ````
2019-01-30 01:24:37 +01:00
"cargo_metadata 0.7.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update clippy and miri submodule
2018-01-30 15:12:12 +01:00
"clippy-mini-macro-test 0.2.0",
update clippy submodule updates to cafef7b576203f166add9ed143979d9775c25219
2018-09-07 09:12:06 +02:00
"clippy_dev 0.0.1",
Update clippy and rls
2018-07-15 00:01:24 +02:00
"clippy_lints 0.0.212",
Update Clippy
2019-03-03 14:48:03 +01:00
"compiletest_rs 0.3.19 (registry+https://github.com/rust-lang/crates.io-index)",
Reduce the numbers of syn versions compiled from 4 to 2 The last remaining one comes from mdbook. Unfortunately updating it breaks everything
2018-12-08 15:11:47 +01:00
"derive-new 0.5.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS
2018-12-10 08:58:08 +01:00
"lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"regex 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Bring in some fixes for `cargo fix` notably
2018-07-31 23:16:55 +02:00
"rustc-workspace-hack 1.0.0",
Update Cargo.lock
2019-01-10 13:42:14 +01:00
"rustc_tools_util 0.1.1",
Automatically enable the `clippy` feature of `rls` if clippy builds
2018-02-09 18:53:41 +01:00
"semver 0.9.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo, rls, miri
2018-12-17 19:23:04 +01:00
"serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"serde_derive 1.0.81 (registry+https://github.com/rust-lang/crates.io-index)",
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
]
[[package]]
name = "clippy-mini-macro-test"
Update clippy and miri submodule
2018-01-30 15:12:12 +01:00
version = "0.2.0"
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
update clippy submodule updates to cafef7b576203f166add9ed143979d9775c25219
2018-09-07 09:12:06 +02:00
[[package]]
name = "clippy_dev"
version = "0.0.1"
dependencies = [
"clap 2.32.0 (registry+https://github.com/rust-lang/crates.io-index)",
submodules: update clippy from f1753522 to 6ce78d12 Changes: ```` wildcard_match_arm: Update lint count. wildcard_match_arm: add nesting issue to known. wildcard_match_arm: lint only enum matches. wildcard_match_arm: update ui test stderr wildcard_match_arm: format test. wilcard_match_arm: run rustfmt. wildcard_match_arm: add lint properly. wildcard_match_arm: rename function. wildcard_match_arm: add simple ui test. wildcard_match_arm: expand lint scope. Change match_wild lint name to WILDCARD_MATCH_ARM. Add match_wild lint (#3649). fetch_prs_between: add .sh file ending cargo fmt Update various docs Use built-in entry_fn detection over self-built cargo fmt Reorganize conditionals: Run faster checks first Maybe fix ICE? Add initial version of const_fn lint Fix `unit_arg` false positive Rustfmt Check hypothetically failing conversion Remove tests for deprecated items Update more changed iterator paths Atomics constants are now handled by the deprecation lint Update changed iterator paths Update const slice processing update test stderr run cargo fmt rustup https://github.com/rust-lang/rust/pull/57907/ Fix documentation for `slow_vector_initialization` rustup https://github.com/rust-lang/rust/pull/57726 Remove unsafe_vector_initialization from added lints Prevent incorrect cast_lossless suggestion in const_fn Incorporate review suggestions Fix dogfood tests on Appveyor test(versioncheck): Use .no_deps() test(versioncheck): Fix version equality check chore(cargo/dependencies/cargo-metadata): Upgrade to 0.7.1 dependencies: update itertools from 0.7 to 0.8 Add script to fetch GitHub PRs between two commits gitattributes: Treat .fixed files as rust files Update changelog with all changes since 0.0.212 Fix `expect_fun_call` lint suggestions ````
2019-01-30 01:24:37 +01:00
"itertools 0.8.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS
2018-12-10 08:58:08 +01:00
"lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"regex 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
"walkdir 2.2.7 (registry+https://github.com/rust-lang/crates.io-index)",
update clippy submodule updates to cafef7b576203f166add9ed143979d9775c25219
2018-09-07 09:12:06 +02:00
]
Update clippy
2018-05-19 13:18:02 +02:00
[[package]]
name = "clippy_lints"
Update clippy and rls
2018-07-15 00:01:24 +02:00
version = "0.0.212"
Update the clippy and miri submodules
2018-05-11 14:11:06 +02:00
dependencies = [
submodules: update clippy from f1753522 to 6ce78d12 Changes: ```` wildcard_match_arm: Update lint count. wildcard_match_arm: add nesting issue to known. wildcard_match_arm: lint only enum matches. wildcard_match_arm: update ui test stderr wildcard_match_arm: format test. wilcard_match_arm: run rustfmt. wildcard_match_arm: add lint properly. wildcard_match_arm: rename function. wildcard_match_arm: add simple ui test. wildcard_match_arm: expand lint scope. Change match_wild lint name to WILDCARD_MATCH_ARM. Add match_wild lint (#3649). fetch_prs_between: add .sh file ending cargo fmt Update various docs Use built-in entry_fn detection over self-built cargo fmt Reorganize conditionals: Run faster checks first Maybe fix ICE? Add initial version of const_fn lint Fix `unit_arg` false positive Rustfmt Check hypothetically failing conversion Remove tests for deprecated items Update more changed iterator paths Atomics constants are now handled by the deprecation lint Update changed iterator paths Update const slice processing update test stderr run cargo fmt rustup https://github.com/rust-lang/rust/pull/57907/ Fix documentation for `slow_vector_initialization` rustup https://github.com/rust-lang/rust/pull/57726 Remove unsafe_vector_initialization from added lints Prevent incorrect cast_lossless suggestion in const_fn Incorporate review suggestions Fix dogfood tests on Appveyor test(versioncheck): Use .no_deps() test(versioncheck): Fix version equality check chore(cargo/dependencies/cargo-metadata): Upgrade to 0.7.1 dependencies: update itertools from 0.7 to 0.8 Add script to fetch GitHub PRs between two commits gitattributes: Treat .fixed files as rust files Update changelog with all changes since 0.0.212 Fix `expect_fun_call` lint suggestions ````
2019-01-30 01:24:37 +01:00
"cargo_metadata 0.7.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update clippy
2018-07-20 09:53:56 +02:00
"if_chain 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)",
submodules: update clippy from f1753522 to 6ce78d12 Changes: ```` wildcard_match_arm: Update lint count. wildcard_match_arm: add nesting issue to known. wildcard_match_arm: lint only enum matches. wildcard_match_arm: update ui test stderr wildcard_match_arm: format test. wilcard_match_arm: run rustfmt. wildcard_match_arm: add lint properly. wildcard_match_arm: rename function. wildcard_match_arm: add simple ui test. wildcard_match_arm: expand lint scope. Change match_wild lint name to WILDCARD_MATCH_ARM. Add match_wild lint (#3649). fetch_prs_between: add .sh file ending cargo fmt Update various docs Use built-in entry_fn detection over self-built cargo fmt Reorganize conditionals: Run faster checks first Maybe fix ICE? Add initial version of const_fn lint Fix `unit_arg` false positive Rustfmt Check hypothetically failing conversion Remove tests for deprecated items Update more changed iterator paths Atomics constants are now handled by the deprecation lint Update changed iterator paths Update const slice processing update test stderr run cargo fmt rustup https://github.com/rust-lang/rust/pull/57907/ Fix documentation for `slow_vector_initialization` rustup https://github.com/rust-lang/rust/pull/57726 Remove unsafe_vector_initialization from added lints Prevent incorrect cast_lossless suggestion in const_fn Incorporate review suggestions Fix dogfood tests on Appveyor test(versioncheck): Use .no_deps() test(versioncheck): Fix version equality check chore(cargo/dependencies/cargo-metadata): Upgrade to 0.7.1 dependencies: update itertools from 0.7 to 0.8 Add script to fetch GitHub PRs between two commits gitattributes: Treat .fixed files as rust files Update changelog with all changes since 0.0.212 Fix `expect_fun_call` lint suggestions ````
2019-01-30 01:24:37 +01:00
"itertools 0.8.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS
2018-12-10 08:58:08 +01:00
"lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"matches 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)",
submodules: update clippy from 2f6881c6 to 754b4c07 Changes: ```` rustup https://github.com/rust-lang/rust/pull/54071/ dependencies: update pulldown-cmark from 0.1 to 0.2 s/file_map/source_map ````
2018-11-23 12:52:47 +01:00
"pulldown-cmark 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update the clippy and miri submodules
2018-05-11 14:11:06 +02:00
"quine-mc_cluskey 0.2.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"regex-syntax 0.6.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update the clippy and miri submodules
2018-05-11 14:11:06 +02:00
"semver 0.9.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo, rls, miri
2018-12-17 19:23:04 +01:00
"serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"serde_derive 1.0.81 (registry+https://github.com/rust-lang/crates.io-index)",
Upgrade `smallvec` to 0.6.7 and use the new `may_dangle` feature.
2018-11-28 22:52:22 +01:00
"smallvec 0.6.7 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"toml 0.4.10 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"unicode-normalization 0.1.7 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"url 1.7.2 (registry+https://github.com/rust-lang/crates.io-index)",
Update the clippy and miri submodules
2018-05-11 14:11:06 +02:00
]
Update RLS and rustfmt.
2018-07-26 23:58:55 +02:00
[[package]]
name = "cloudabi"
version = "0.0.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"bitflags 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS and rustfmt.
2018-07-26 23:58:55 +02:00
]
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
[[package]]
name = "cmake"
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
version = "0.1.33"
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update cc crate to include Armv8-M changes
2019-01-09 15:51:22 +01:00
"cc 1.0.28 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
]
Update rustfmt and rls
2018-04-26 00:11:28 +02:00
[[package]]
name = "colored"
version = "1.6.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"lazy_static 0.2.11 (registry+https://github.com/rust-lang/crates.io-index)",
]
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
[[package]]
name = "commoncrypto"
version = "0.2.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"commoncrypto-sys 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "commoncrypto-sys"
version = "0.2.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Reintroduce deprecated `collections` crate
2017-06-17 21:01:18 +02:00
]
rustbuild: Use `cargo metadata` to learn about DAG This updates the commit to use workspaces to use `cargo metadata` instead of hardcoded lists about what to test. This should help us be resilient to updates in the future on behalf of the crate DAG and minimize the amount of files that need to be touched.
2016-10-07 08:30:38 +02:00
[[package]]
name = "compiler_builtins"
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
version = "0.1.8"
std: Depend directly on crates.io crates 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-11-20 06:52:50 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
rustbuild: Use `cargo metadata` to learn about DAG This updates the commit to use workspaces to use `cargo metadata` instead of hardcoded lists about what to test. This should help us be resilient to updates in the future on behalf of the crate DAG and minimize the amount of files that need to be touched.
2016-10-07 08:30:38 +02:00
dependencies = [
Update cc crate to include Armv8-M changes
2019-01-09 15:51:22 +01:00
"cc 1.0.28 (registry+https://github.com/rust-lang/crates.io-index)",
std: Depend directly on crates.io crates 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-11-20 06:52:50 +01:00
"rustc-std-workspace-core 1.0.0",
rustbuild: Use `cargo metadata` to learn about DAG This updates the commit to use workspaces to use `cargo metadata` instead of hardcoded lists about what to test. This should help us be resilient to updates in the future on behalf of the crate DAG and minimize the amount of files that need to be touched.
2016-10-07 08:30:38 +02:00
]
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
[[package]]
name = "compiletest"
version = "0.0.0"
dependencies = [
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
"diff 0.1.11 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"env_logger 0.5.13 (registry+https://github.com/rust-lang/crates.io-index)",
"filetime 0.2.4 (registry+https://github.com/rust-lang/crates.io-index)",
Bump to 1.27.0 Also update some `Cargo.lock` dependencies, finishing up some final steps of our [release process]! This doesn't update the bootstrap compiler just yet but that will come in a follow-up PR. [release process]: https://forge.rust-lang.org/release-process.html
2018-04-02 17:43:55 +02:00
"getopts 0.2.17 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS
2018-12-10 08:58:08 +01:00
"lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"miow 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"regex 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo, rls, miri
2018-12-17 19:23:04 +01:00
"rustfix 0.4.4 (registry+https://github.com/rust-lang/crates.io-index)",
"serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"serde_derive 1.0.81 (registry+https://github.com/rust-lang/crates.io-index)",
"serde_json 1.0.33 (registry+https://github.com/rust-lang/crates.io-index)",
Fix Cargo.lock.
2018-12-17 13:40:40 +01:00
"walkdir 2.2.7 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
]
Run RLS tests
2017-06-30 20:58:54 +02:00
[[package]]
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
name = "compiletest_rs"
Update Clippy
2019-03-03 14:48:03 +01:00
version = "0.3.19"
Set python binary name to python 2.7
2017-07-14 12:30:17 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
"diff 0.1.11 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"filetime 0.2.4 (registry+https://github.com/rust-lang/crates.io-index)",
Bump to 1.27.0 Also update some `Cargo.lock` dependencies, finishing up some final steps of our [release process]! This doesn't update the bootstrap compiler just yet but that will come in a follow-up PR. [release process]: https://forge.rust-lang.org/release-process.html
2018-04-02 17:43:55 +02:00
"getopts 0.2.17 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"miow 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"regex 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
submodules: update clippy from 39bd8449 to c63b6349 Changes: ```` Revert "tests: used_underscore_binding_macro: disable random_state lint." Revert "Auto merge of #3603 - xfix:random-state-lint, r=phansch" rustup https://github.com/rust-lang/rust/pull/56837 rustup (don't know the exact PR unfortunately) Add itertools to integration tests tests: used_underscore_binding_macro: disable random_state lint. Trigger `use_self` lint in local macros Add run-rustfix where it already passes rustup: https://github.com/rust-lang/rust/pull/55517 Make clippy work with parallel rustc Add ui/for_kv_map test for false positive in #1279 Update to latest compiletest-rs release add testcase for #3462 deps: bump rustc_tools_util version from 0.1.0 to 0.1.1 just in case... Use compiletest's aux-build header instead of include macro rustc_tool_utils: fix failure to create proper non-repo version string when used in crates on crates.io, bump version rustfmt UI test cleanup: Extract ifs_same_cond tests Extract IteratorFalsePositives into option_helpers.rs UI test cleanup: Extract for_kv_map lint tests UI test cleanup: Extract lint from methods.rs test Fix test for rust-lang/rust#57250 Limit infinite_iter collect() check to known types Some improvements to util documentation Use hashset for name blacklist Reformat random_state tests Use node_id_to_type_opt instead of node_it_to_type in random_state Check pattern equality while checking declaration equality random_state lint Move constant write checks to temporary_assignment lint Use an FxHashSet for valid idents in documentation lint Fix suggestion for unnecessary_ref lint Update CONTRIBUTING.md for rustfix tests Update .fixed files via update-references.sh Run rustfix on first UI test Use WIP branch for compiletest_rs ````
2019-01-05 15:40:10 +01:00
"rustfix 0.4.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo, rls, miri
2018-12-17 19:23:04 +01:00
"serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"serde_derive 1.0.81 (registry+https://github.com/rust-lang/crates.io-index)",
"serde_json 1.0.33 (registry+https://github.com/rust-lang/crates.io-index)",
"tempfile 3.0.5 (registry+https://github.com/rust-lang/crates.io-index)",
Update miri
2019-03-02 20:58:38 +01:00
"tester 0.5.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
Set python binary name to python 2.7
2017-07-14 12:30:17 +02:00
]
Update Cargo.lock
2019-02-18 10:32:58 +01:00
[[package]]
name = "constant_time_eq"
version = "0.1.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
[[package]]
name = "core"
version = "0.0.0"
Update Cargo submodule Required moving all fulldeps tests depending on `rand` to different locations as now there's multiple `rand` crates that can't be implicitly linked against.
2018-02-26 18:07:16 +01:00
dependencies = [
std: Depend directly on crates.io crates 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-11-20 06:52:50 +01:00
"rand 0.6.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Required moving all fulldeps tests depending on `rand` to different locations as now there's multiple `rand` crates that can't be implicitly linked against.
2018-02-26 18:07:16 +01:00
]
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
Update RLS and Cargo
2017-08-24 07:52:28 +02:00
[[package]]
name = "core-foundation"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "0.6.3"
Update RLS and Cargo
2017-08-24 07:52:28 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"core-foundation-sys 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS and Cargo
2017-08-24 07:52:28 +02:00
]
[[package]]
name = "core-foundation-sys"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "0.6.2"
Update RLS and Cargo
2017-08-24 07:52:28 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Point RLS submodule at a branch with required changes And cargo update
2017-07-19 03:32:12 +02:00
[[package]]
name = "crates-io"
Update cargo, rls
2019-03-04 22:18:44 +01:00
version = "0.24.0"
Point RLS submodule at a branch with required changes And cargo update
2017-07-19 03:32:12 +02:00
dependencies = [
Update Cargo submodule Hopefully a relatively routine update!
2018-11-09 21:55:25 +01:00
"curl 0.4.19 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo
2019-02-03 23:42:29 +01:00
"failure 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo
2019-03-29 04:13:13 +01:00
"http 0.1.16 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo, rls, miri
2018-12-17 19:23:04 +01:00
"serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"serde_derive 1.0.81 (registry+https://github.com/rust-lang/crates.io-index)",
"serde_json 1.0.33 (registry+https://github.com/rust-lang/crates.io-index)",
"url 1.7.2 (registry+https://github.com/rust-lang/crates.io-index)",
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
]
rustbuild: Switch back to using hard links The `copy` function historically in rustbuild used hard links to speed up the copy operations that it does. This logic was backed out, however, in #39518 due to a bug that only showed up on Windows, described in #39504. The cause described in #39504 happened because Cargo, on a fresh build, would overwrite the previous artifacts with new hard links that Cargo itself manages. This behavior in Cargo was fixed in rust-lang/cargo#4390 where it no longer should overwrite files on fresh builds, opportunistically leaving the filesystem intact and not touching it. Hopefully this can help speed up local builds by doing fewer copies all over the place!
2017-09-02 05:46:51 +02:00
[[package]]
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
name = "crc"
version = "1.8.1"
rustbuild: Switch back to using hard links The `copy` function historically in rustbuild used hard links to speed up the copy operations that it does. This logic was backed out, however, in #39518 due to a bug that only showed up on Windows, described in #39504. The cause described in #39504 happened because Cargo, on a fresh build, would overwrite the previous artifacts with new hard links that Cargo itself manages. This behavior in Cargo was fixed in rust-lang/cargo#4390 where it no longer should overwrite files on fresh builds, opportunistically leaving the filesystem intact and not touching it. Hopefully this can help speed up local builds by doing fewer copies all over the place!
2017-09-02 05:46:51 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
dependencies = [
"build_const 0.2.1 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "crc32fast"
version = "1.1.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"cfg-if 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)",
]
rustbuild: Switch back to using hard links The `copy` function historically in rustbuild used hard links to speed up the copy operations that it does. This logic was backed out, however, in #39518 due to a bug that only showed up on Windows, described in #39504. The cause described in #39504 happened because Cargo, on a fresh build, would overwrite the previous artifacts with new hard links that Cargo itself manages. This behavior in Cargo was fixed in rust-lang/cargo#4390 where it no longer should overwrite files on fresh builds, opportunistically leaving the filesystem intact and not touching it. Hopefully this can help speed up local builds by doing fewer copies all over the place!
2017-09-02 05:46:51 +02:00
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
[[package]]
name = "crossbeam-channel"
version = "0.3.4"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"crossbeam-epoch 0.7.0 (registry+https://github.com/rust-lang/crates.io-index)",
"crossbeam-utils 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)",
"parking_lot 0.7.1 (registry+https://github.com/rust-lang/crates.io-index)",
"rand 0.6.1 (registry+https://github.com/rust-lang/crates.io-index)",
"smallvec 0.6.7 (registry+https://github.com/rust-lang/crates.io-index)",
]
Update RLS
2018-02-26 04:15:45 +01:00
[[package]]
name = "crossbeam-deque"
version = "0.2.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Bump to 1.27.0 Also update some `Cargo.lock` dependencies, finishing up some final steps of our [release process]! This doesn't update the bootstrap compiler just yet but that will come in a follow-up PR. [release process]: https://forge.rust-lang.org/release-process.html
2018-04-02 17:43:55 +02:00
"crossbeam-epoch 0.3.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS
2018-02-26 04:15:45 +01:00
"crossbeam-utils 0.2.2 (registry+https://github.com/rust-lang/crates.io-index)",
]
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
[[package]]
name = "crossbeam-deque"
version = "0.6.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"crossbeam-epoch 0.7.0 (registry+https://github.com/rust-lang/crates.io-index)",
"crossbeam-utils 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)",
]
Update RLS
2018-02-26 04:15:45 +01:00
[[package]]
name = "crossbeam-epoch"
Bump to 1.27.0 Also update some `Cargo.lock` dependencies, finishing up some final steps of our [release process]! This doesn't update the bootstrap compiler just yet but that will come in a follow-up PR. [release process]: https://forge.rust-lang.org/release-process.html
2018-04-02 17:43:55 +02:00
version = "0.3.1"
Update RLS
2018-02-26 04:15:45 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"arrayvec 0.4.7 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"cfg-if 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS
2018-02-26 04:15:45 +01:00
"crossbeam-utils 0.2.2 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS
2018-12-10 08:58:08 +01:00
"lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS
2018-02-26 04:15:45 +01:00
"memoffset 0.2.1 (registry+https://github.com/rust-lang/crates.io-index)",
"nodrop 0.1.12 (registry+https://github.com/rust-lang/crates.io-index)",
"scopeguard 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)",
]
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
[[package]]
name = "crossbeam-epoch"
version = "0.7.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"arrayvec 0.4.7 (registry+https://github.com/rust-lang/crates.io-index)",
"cfg-if 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)",
"crossbeam-utils 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)",
"lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
"memoffset 0.2.1 (registry+https://github.com/rust-lang/crates.io-index)",
"scopeguard 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)",
]
Update RLS
2018-02-26 04:15:45 +01:00
[[package]]
name = "crossbeam-utils"
version = "0.2.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"cfg-if 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS
2018-02-26 04:15:45 +01:00
]
Update Cargo submodule Brings in some fixes and stabilizations!
2018-11-16 12:08:23 +01:00
[[package]]
name = "crossbeam-utils"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "0.6.2"
Update Cargo submodule Brings in some fixes and stabilizations!
2018-11-16 12:08:23 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"cfg-if 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Brings in some fixes and stabilizations!
2018-11-16 12:08:23 +01:00
]
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
[[package]]
name = "crypto-hash"
Update Cargo submodule Required moving all fulldeps tests depending on `rand` to different locations as now there's multiple `rand` crates that can't be implicitly linked against.
2018-02-26 18:07:16 +01:00
version = "0.3.1"
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"commoncrypto 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"hex 0.3.2 (registry+https://github.com/rust-lang/crates.io-index)",
Upgrade openssl and openssl-sys
2019-01-02 11:06:36 +01:00
"openssl 0.10.16 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
]
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
[[package]]
name = "curl"
Update Cargo submodule Hopefully a relatively routine update!
2018-11-09 21:55:25 +01:00
version = "0.4.19"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule Hopefully a relatively routine update!
2018-11-09 21:55:25 +01:00
"curl-sys 0.4.15 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo and its dependencies This'll probably have a bunch of build errors, so let's try and head those off and find them sooner rather than later!
2018-01-08 22:56:22 +01:00
"kernel32-sys 0.2.2 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo and its dependencies Just a routine update!
2017-12-10 18:42:49 +01:00
"openssl-probe 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)",
Upgrade openssl and openssl-sys
2019-01-02 11:06:36 +01:00
"openssl-sys 0.9.40 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"schannel 0.1.14 (registry+https://github.com/rust-lang/crates.io-index)",
"socket2 0.3.8 (registry+https://github.com/rust-lang/crates.io-index)",
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
"winapi 0.2.8 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "curl-sys"
Update Cargo submodule Hopefully a relatively routine update!
2018-11-09 21:55:25 +01:00
version = "0.4.15"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update cc crate to include Armv8-M changes
2019-01-09 15:51:22 +01:00
"cc 1.0.28 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"libnghttp2-sys 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)",
"libz-sys 1.0.25 (registry+https://github.com/rust-lang/crates.io-index)",
Upgrade openssl and openssl-sys
2019-01-02 11:06:36 +01:00
"openssl-sys 0.9.40 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"pkg-config 0.3.14 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"vcpkg 0.2.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update to the oxidized rust-installer
2017-05-09 00:01:13 +02:00
]
bump polonius engine
2018-05-29 13:52:51 +02:00
[[package]]
name = "datafrog"
adopt polonius-engine 0.6.2 Also datafrog 2.0.1, which works around a rustdoc bug
2019-01-02 20:45:22 +01:00
version = "2.0.1"
bump polonius engine
2018-05-29 13:52:51 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
[[package]]
name = "derive-new"
Reduce the numbers of syn versions compiled from 4 to 2 The last remaining one comes from mdbook. Unfortunately updating it breaks everything
2018-12-08 15:11:47 +01:00
version = "0.5.6"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Reduce the numbers of syn versions compiled from 4 to 2 The last remaining one comes from mdbook. Unfortunately updating it breaks everything
2018-12-08 15:11:47 +01:00
"proc-macro2 0.4.24 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"quote 0.6.10 (registry+https://github.com/rust-lang/crates.io-index)",
"syn 0.15.22 (registry+https://github.com/rust-lang/crates.io-index)",
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
]
Update RLS and rustfmt.
2018-07-26 23:58:55 +02:00
[[package]]
name = "derive_more"
Update RLS and Rustfmt
2018-11-19 05:21:10 +01:00
version = "0.13.0"
Update RLS and rustfmt.
2018-07-26 23:58:55 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update RLS and Rustfmt
2018-11-19 05:21:10 +01:00
"proc-macro2 0.4.24 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"quote 0.6.10 (registry+https://github.com/rust-lang/crates.io-index)",
"rustc_version 0.2.3 (registry+https://github.com/rust-lang/crates.io-index)",
"syn 0.15.22 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS and rustfmt.
2018-07-26 23:58:55 +02:00
]
use diff crate for compile-fail test diagnostics #41474
2017-04-27 21:41:18 +02:00
[[package]]
name = "diff"
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
version = "0.1.11"
use diff crate for compile-fail test diagnostics #41474
2017-04-27 21:41:18 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Add tests to rustbuild In order to run tests, previous commits have cfg'd out various parts of rustbuild. Generally speaking, these are filesystem-related operations and process-spawning related parts. Then, rustbuild is run "as normal" and the various steps that where run are retrieved from the cache and checked against the expected results. Note that this means that the current implementation primarily tests "what" we build, but doesn't actually test that what we build *will* build. In other words, it doesn't do any form of dependency verification for any crate. This is possible to implement, but is considered future work. This implementation strives to cfg out as little code as possible; it also does not currently test anywhere near all of rustbuild. The current tests are also not checked for "correctness," rather, they simply represent what we do as of this commit, which may be wrong. Test cases are drawn from the old implementation of rustbuild, though the expected results may vary.
2018-03-10 15:03:06 +01:00
[[package]]
name = "difference"
version = "2.0.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
Update to newer version of mdbook(2)
2019-01-19 03:39:37 +01:00
[[package]]
name = "digest"
version = "0.7.6"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"generic-array 0.9.0 (registry+https://github.com/rust-lang/crates.io-index)",
]
update miri
2018-11-28 21:22:45 +01:00
[[package]]
name = "directories"
version = "1.0.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
update miri
2018-11-28 21:22:45 +01:00
"winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
]
Update Cargo.lock
2019-02-18 10:32:58 +01:00
[[package]]
name = "dirs"
version = "1.0.4"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock
2019-02-18 10:32:58 +01:00
"redox_users 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
"winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
]
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
[[package]]
name = "dlmalloc"
Update dlmalloc to 0.1.3
2019-02-26 01:18:22 +01:00
version = "0.1.3"
std: Depend directly on crates.io crates 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-11-20 06:52:50 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
dependencies = [
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"compiler_builtins 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)",
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
std: Depend directly on crates.io crates 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-11-20 06:52:50 +01:00
"rustc-std-workspace-core 1.0.0",
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
]
[[package]]
name = "either"
Bump to 1.27.0 Also update some `Cargo.lock` dependencies, finishing up some final steps of our [release process]! This doesn't update the bootstrap compiler just yet but that will come in a follow-up PR. [release process]: https://forge.rust-lang.org/release-process.html
2018-04-02 17:43:55 +02:00
version = "1.5.0"
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
[[package]]
name = "elasticlunr-rs"
Reduce the numbers of syn versions compiled from 4 to 2 The last remaining one comes from mdbook. Unfortunately updating it breaks everything
2018-12-08 15:11:47 +01:00
version = "2.3.4"
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update RLS
2018-12-10 08:58:08 +01:00
"lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"regex 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo, rls, miri
2018-12-17 19:23:04 +01:00
"serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"serde_derive 1.0.81 (registry+https://github.com/rust-lang/crates.io-index)",
"serde_json 1.0.33 (registry+https://github.com/rust-lang/crates.io-index)",
Reduce the numbers of syn versions compiled from 4 to 2 The last remaining one comes from mdbook. Unfortunately updating it breaks everything
2018-12-08 15:11:47 +01:00
"strum 0.11.0 (registry+https://github.com/rust-lang/crates.io-index)",
"strum_macros 0.11.0 (registry+https://github.com/rust-lang/crates.io-index)",
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
]
rustc: implement and use Default on more types.
2018-07-25 14:44:06 +02:00
[[package]]
name = "ena"
Update to `ena` 0.11.0. This version has some significant speed-ups relating to snapshotting.
2018-11-02 09:46:59 +01:00
version = "0.11.0"
rustc: implement and use Default on more types.
2018-07-25 14:44:06 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
rustc: implement and use Default on more types.
2018-07-25 14:44:06 +02:00
]
Update ena
2019-03-19 22:30:07 +01:00
[[package]]
name = "ena"
Update ena to version 0.13.0
2019-03-25 16:45:44 +01:00
version = "0.13.0"
Update ena
2019-03-19 22:30:07 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
]
Update Cargo submodule to master Just a routine update
2018-01-25 05:01:42 +01:00
[[package]]
name = "env_logger"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "0.5.13"
Update Cargo submodule to master Just a routine update
2018-01-25 05:01:42 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
revert accidental atty downgrade
2018-07-27 15:10:52 +02:00
"atty 0.2.11 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"humantime 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
"regex 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
"termcolor 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule to master Just a routine update
2018-01-25 05:01:42 +01:00
]
Update Cargo submodule Brings in some fixes and stabilizations!
2018-11-16 12:08:23 +01:00
[[package]]
name = "env_logger"
version = "0.6.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"atty 0.2.11 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"humantime 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
"regex 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
"termcolor 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Brings in some fixes and stabilizations!
2018-11-16 12:08:23 +01:00
]
Update to the oxidized rust-installer
2017-05-09 00:01:13 +02:00
[[package]]
name = "error-chain"
rustbuild: Switch back to using hard links The `copy` function historically in rustbuild used hard links to speed up the copy operations that it does. This logic was backed out, however, in #39518 due to a bug that only showed up on Windows, described in #39504. The cause described in #39504 happened because Cargo, on a fresh build, would overwrite the previous artifacts with new hard links that Cargo itself manages. This behavior in Cargo was fixed in rust-lang/cargo#4390 where it no longer should overwrite files on fresh builds, opportunistically leaving the filesystem intact and not touching it. Hopefully this can help speed up local builds by doing fewer copies all over the place!
2017-09-02 05:46:51 +02:00
version = "0.11.0"
Update cargo version
2017-07-29 14:35:09 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
bump backtrace version to get prettier pretty-printing
2018-12-11 22:36:24 +01:00
"backtrace 0.3.11 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo version
2017-07-29 14:35:09 +02:00
]
update miri
2018-07-13 10:34:50 +02:00
[[package]]
name = "error-chain"
version = "0.12.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
bump backtrace version to get prettier pretty-printing
2018-12-11 22:36:24 +01:00
"backtrace 0.3.11 (registry+https://github.com/rust-lang/crates.io-index)",
update miri
2018-07-13 10:34:50 +02:00
]
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
[[package]]
name = "error_index_generator"
version = "0.0.0"
Build rustdoc on-demand. Rustdoc is no longer compiled in every stage, alongside rustc, instead it is only compiled when requested, and generally only for the last stage.
2017-07-23 04:01:58 +02:00
dependencies = [
"rustdoc 0.0.0",
]
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
Update Cargo and its dependencies Just a routine update!
2017-12-10 18:42:49 +01:00
[[package]]
name = "failure"
Update cargo
2019-02-03 23:42:29 +01:00
version = "0.1.5"
Update Cargo and its dependencies Just a routine update!
2017-12-10 18:42:49 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
bump backtrace version to get prettier pretty-printing
2018-12-11 22:36:24 +01:00
"backtrace 0.3.11 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo
2019-02-03 23:42:29 +01:00
"failure_derive 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo and its dependencies Just a routine update!
2017-12-10 18:42:49 +01:00
]
[[package]]
name = "failure_derive"
Update cargo
2019-02-03 23:42:29 +01:00
version = "0.1.5"
Update Cargo and its dependencies Just a routine update!
2017-12-10 18:42:49 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update RLS and Rustfmt
2018-11-19 05:21:10 +01:00
"proc-macro2 0.4.24 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"quote 0.6.10 (registry+https://github.com/rust-lang/crates.io-index)",
"syn 0.15.22 (registry+https://github.com/rust-lang/crates.io-index)",
Reduce the numbers of syn versions compiled from 4 to 2 The last remaining one comes from mdbook. Unfortunately updating it breaks everything
2018-12-08 15:11:47 +01:00
"synstructure 0.10.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo and its dependencies Just a routine update!
2017-12-10 18:42:49 +01:00
]
Update to newer version of mdbook(2)
2019-01-19 03:39:37 +01:00
[[package]]
name = "fake-simd"
version = "0.1.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
Update the Cargo submodule
2018-04-18 17:43:59 +02:00
[[package]]
name = "filetime"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "0.2.4"
Update the Cargo submodule
2018-04-18 17:43:59 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"cfg-if 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"redox_syscall 0.1.43 (registry+https://github.com/rust-lang/crates.io-index)",
Update the Cargo submodule
2018-04-18 17:43:59 +02:00
]
Implement generating graphs of the build steps
2018-03-27 12:44:33 +02:00
[[package]]
name = "fixedbitset"
version = "0.1.9"
source = "registry+https://github.com/rust-lang/crates.io-index"
Update cargo
2017-12-31 15:34:29 +01:00
[[package]]
name = "flate2"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "1.0.6"
Update cargo
2017-12-31 15:34:29 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"crc32fast 1.1.2 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"libz-sys 1.0.25 (registry+https://github.com/rust-lang/crates.io-index)",
"miniz-sys 0.1.11 (registry+https://github.com/rust-lang/crates.io-index)",
"miniz_oxide_c_api 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo
2017-12-31 15:34:29 +01:00
]
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
[[package]]
name = "fmt_macros"
version = "0.0.0"
Update Cargo to ffab51954ec32d55631c37a8730bb24915fc090b https://github.com/rust-lang/cargo/pull/4123 added the [patch] section of the manifest
2017-07-18 23:26:55 +02:00
[[package]]
name = "fnv"
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
version = "1.0.6"
Update Cargo to ffab51954ec32d55631c37a8730bb24915fc090b https://github.com/rust-lang/cargo/pull/4123 added the [patch] section of the manifest
2017-07-18 23:26:55 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
[[package]]
name = "foreign-types"
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
version = "0.3.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"foreign-types-shared 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "foreign-types-shared"
version = "0.1.1"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Add x86_64-fortanix-unknown-sgx target to libstd and dependencies 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-08-28 06:33:26 +02:00
[[package]]
name = "fortanix-sgx-abi"
Add `std::os::fortanix_sgx` module
2018-12-19 12:56:17 +01:00
version = "0.3.2"
std: Depend directly on crates.io crates 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-11-20 06:52:50 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Add x86_64-fortanix-unknown-sgx target to libstd and dependencies 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-08-28 06:33:26 +02:00
dependencies = [
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"compiler_builtins 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)",
std: Depend directly on crates.io crates 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-11-20 06:52:50 +01:00
"rustc-std-workspace-core 1.0.0",
Add x86_64-fortanix-unknown-sgx target to libstd and dependencies 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-08-28 06:33:26 +02:00
]
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
[[package]]
name = "fs2"
Update Cargo and its dependencies This'll probably have a bunch of build errors, so let's try and head those off and find them sooner rather than later!
2018-01-08 22:56:22 +01:00
version = "0.4.3"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
]
Use `jemalloc-sys` on Linux and OSX compilers 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-21 04:15:06 +02:00
[[package]]
name = "fs_extra"
version = "1.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
Update RLS, Rustfmt, Cargo, and Clippy
2018-07-06 02:34:00 +02:00
[[package]]
name = "fst"
version = "0.3.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"byteorder 1.2.7 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS, Rustfmt, Cargo, and Clippy
2018-07-06 02:34:00 +02:00
]
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
[[package]]
name = "fuchsia-zircon"
Update Cargo and its dependencies This'll probably have a bunch of build errors, so let's try and head those off and find them sooner rather than later!
2018-01-08 22:56:22 +01:00
version = "0.3.3"
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"bitflags 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo and its dependencies This'll probably have a bunch of build errors, so let's try and head those off and find them sooner rather than later!
2018-01-08 22:56:22 +01:00
"fuchsia-zircon-sys 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)",
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
]
[[package]]
name = "fuchsia-zircon-sys"
Update Cargo and its dependencies This'll probably have a bunch of build errors, so let's try and head those off and find them sooner rather than later!
2018-01-08 22:56:22 +01:00
version = "0.3.3"
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
[[package]]
name = "futf"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
version = "0.1.4"
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"mac 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"new_debug_unreachable 1.0.1 (registry+https://github.com/rust-lang/crates.io-index)",
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
]
Point RLS submodule at a branch with required changes And cargo update
2017-07-19 03:32:12 +02:00
[[package]]
name = "futures"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
version = "0.1.21"
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Update cargo
2018-08-14 23:27:26 +02:00
[[package]]
name = "fwdansi"
version = "1.0.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"memchr 2.1.1 (registry+https://github.com/rust-lang/crates.io-index)",
"termcolor 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo
2018-08-14 23:27:26 +02:00
]
Update to newer version of mdbook(2)
2019-01-19 03:39:37 +01:00
[[package]]
name = "generic-array"
version = "0.9.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"typenum 1.10.0 (registry+https://github.com/rust-lang/crates.io-index)",
]
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
[[package]]
name = "getopts"
Bump to 1.27.0 Also update some `Cargo.lock` dependencies, finishing up some final steps of our [release process]! This doesn't update the bootstrap compiler just yet but that will come in a follow-up PR. [release process]: https://forge.rust-lang.org/release-process.html
2018-04-02 17:43:55 +02:00
version = "0.2.17"
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
[[package]]
name = "git2"
Update Cargo.lock
2019-01-10 13:42:14 +01:00
version = "0.8.0"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"bitflags 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo, rls, miri
2018-12-17 19:23:04 +01:00
"libgit2-sys 0.7.11 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo and its dependencies Just a routine update!
2017-12-10 18:42:49 +01:00
"openssl-probe 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)",
Upgrade openssl and openssl-sys
2019-01-02 11:06:36 +01:00
"openssl-sys 0.9.40 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"url 1.7.2 (registry+https://github.com/rust-lang/crates.io-index)",
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
]
[[package]]
name = "git2-curl"
Update Cargo.lock
2019-01-10 13:42:14 +01:00
version = "0.9.0"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule Hopefully a relatively routine update!
2018-11-09 21:55:25 +01:00
"curl 0.4.19 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock
2019-01-10 13:42:14 +01:00
"git2 0.8.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
"url 1.7.2 (registry+https://github.com/rust-lang/crates.io-index)",
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
]
[[package]]
name = "glob"
Update cargo
2019-03-12 21:34:47 +01:00
version = "0.3.0"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Update Cargo to ffab51954ec32d55631c37a8730bb24915fc090b https://github.com/rust-lang/cargo/pull/4123 added the [patch] section of the manifest
2017-07-18 23:26:55 +02:00
[[package]]
name = "globset"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "0.4.2"
Update Cargo to ffab51954ec32d55631c37a8730bb24915fc090b https://github.com/rust-lang/cargo/pull/4123 added the [patch] section of the manifest
2017-07-18 23:26:55 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"aho-corasick 0.6.9 (registry+https://github.com/rust-lang/crates.io-index)",
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
"fnv 1.0.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
"memchr 2.1.1 (registry+https://github.com/rust-lang/crates.io-index)",
"regex 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo to ffab51954ec32d55631c37a8730bb24915fc090b https://github.com/rust-lang/cargo/pull/4123 added the [patch] section of the manifest
2017-07-18 23:26:55 +02:00
]
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
[[package]]
name = "graphviz"
version = "0.0.0"
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
[[package]]
name = "handlebars"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
version = "0.32.4"
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update RLS
2018-12-10 08:58:08 +01:00
"lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Bump to 1.27.0 Also update some `Cargo.lock` dependencies, finishing up some final steps of our [release process]! This doesn't update the bootstrap compiler just yet but that will come in a follow-up PR. [release process]: https://forge.rust-lang.org/release-process.html
2018-04-02 17:43:55 +02:00
"pest 1.0.6 (registry+https://github.com/rust-lang/crates.io-index)",
Reduce the numbers of syn versions compiled from 4 to 2 The last remaining one comes from mdbook. Unfortunately updating it breaks everything
2018-12-08 15:11:47 +01:00
"pest_derive 1.0.8 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"quick-error 1.2.2 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"regex 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo, rls, miri
2018-12-17 19:23:04 +01:00
"serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"serde_json 1.0.33 (registry+https://github.com/rust-lang/crates.io-index)",
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
]
Update to newer version of mdbook(2)
2019-01-19 03:39:37 +01:00
[[package]]
name = "handlebars"
version = "1.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
"pest 2.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
"pest_derive 2.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
"quick-error 1.2.2 (registry+https://github.com/rust-lang/crates.io-index)",
"regex 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
"serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)",
"serde_json 1.0.33 (registry+https://github.com/rust-lang/crates.io-index)",
"walkdir 2.2.7 (registry+https://github.com/rust-lang/crates.io-index)",
]
Reduce the numbers of syn versions compiled from 4 to 2 The last remaining one comes from mdbook. Unfortunately updating it breaks everything
2018-12-08 15:11:47 +01:00
[[package]]
name = "heck"
version = "0.3.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"unicode-segmentation 1.2.1 (registry+https://github.com/rust-lang/crates.io-index)",
]
Update Cargo and its dependencies This'll probably have a bunch of build errors, so let's try and head those off and find them sooner rather than later!
2018-01-08 22:56:22 +01:00
[[package]]
name = "hex"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
version = "0.3.2"
Update Cargo and its dependencies This'll probably have a bunch of build errors, so let's try and head those off and find them sooner rather than later!
2018-01-08 22:56:22 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Point RLS submodule at a branch with required changes And cargo update
2017-07-19 03:32:12 +02:00
[[package]]
name = "home"
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
version = "0.3.3"
Point RLS submodule at a branch with required changes And cargo update
2017-07-19 03:32:12 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Bump racer and home This removes 10 dependencies from the build :tada:
2018-03-21 03:04:09 +01:00
"scopeguard 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
Point RLS submodule at a branch with required changes And cargo update
2017-07-19 03:32:12 +02:00
]
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
[[package]]
name = "html5ever"
Reduce the numbers of syn versions compiled from 4 to 2 The last remaining one comes from mdbook. Unfortunately updating it breaks everything
2018-12-08 15:11:47 +01:00
version = "0.22.5"
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
"mac 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)",
"markup5ever 0.7.2 (registry+https://github.com/rust-lang/crates.io-index)",
Reduce the numbers of syn versions compiled from 4 to 2 The last remaining one comes from mdbook. Unfortunately updating it breaks everything
2018-12-08 15:11:47 +01:00
"proc-macro2 0.4.24 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"quote 0.6.10 (registry+https://github.com/rust-lang/crates.io-index)",
"syn 0.15.22 (registry+https://github.com/rust-lang/crates.io-index)",
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
]
Update cargo
2019-03-29 04:13:13 +01:00
[[package]]
name = "http"
version = "0.1.16"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"bytes 0.4.11 (registry+https://github.com/rust-lang/crates.io-index)",
"fnv 1.0.6 (registry+https://github.com/rust-lang/crates.io-index)",
"itoa 0.4.3 (registry+https://github.com/rust-lang/crates.io-index)",
]
Update env_logger to 0.5.4 It looks like this cuts down on the number of dependencies in env_logger and notably cuts out a difference between a shared dependency of rls/cargo. My goal here is to ensure that when we compile the RLS/Cargo on CI we only compile Cargo once, and this is one step towards that!
2018-03-01 20:08:48 +01:00
[[package]]
name = "humantime"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "1.2.0"
Update env_logger to 0.5.4 It looks like this cuts down on the number of dependencies in env_logger and notably cuts out a difference between a shared dependency of rls/cargo. My goal here is to ensure that when we compile the RLS/Cargo on CI we only compile Cargo once, and this is one step towards that!
2018-03-01 20:08:48 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"quick-error 1.2.2 (registry+https://github.com/rust-lang/crates.io-index)",
Update env_logger to 0.5.4 It looks like this cuts down on the number of dependencies in env_logger and notably cuts out a difference between a shared dependency of rls/cargo. My goal here is to ensure that when we compile the RLS/Cargo on CI we only compile Cargo once, and this is one step towards that!
2018-03-01 20:08:48 +01:00
]
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
[[package]]
name = "idna"
Update Cargo submodule
2018-07-17 18:04:22 +02:00
version = "0.1.5"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"matches 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)",
update crate dependencies I wanted to update mdbook's version. This ended up updating a bunch of other stuff too.
2017-06-27 19:33:32 +02:00
"unicode-bidi 0.3.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"unicode-normalization 0.1.7 (registry+https://github.com/rust-lang/crates.io-index)",
Add Cargo as a submodule
2017-02-15 23:55:26 +01:00
]
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
[[package]]
name = "if_chain"
Update clippy
2018-07-20 09:53:56 +02:00
version = "0.1.3"
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Update Cargo to ffab51954ec32d55631c37a8730bb24915fc090b https://github.com/rust-lang/cargo/pull/4123 added the [patch] section of the manifest
2017-07-18 23:26:55 +02:00
[[package]]
name = "ignore"
Update parking_lot to 0.7 Unfortunately this'll dupe parking_lot until the data_structures crate is published and be updated in rls in conjunction with crossbeam-channel
2019-02-22 13:49:19 +01:00
version = "0.4.6"
Update Cargo to ffab51954ec32d55631c37a8730bb24915fc090b https://github.com/rust-lang/cargo/pull/4123 added the [patch] section of the manifest
2017-07-18 23:26:55 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update parking_lot to 0.7 Unfortunately this'll dupe parking_lot until the data_structures crate is published and be updated in rls in conjunction with crossbeam-channel
2019-02-22 13:49:19 +01:00
"crossbeam-channel 0.3.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"globset 0.4.2 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS
2018-12-10 08:58:08 +01:00
"lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
"memchr 2.1.1 (registry+https://github.com/rust-lang/crates.io-index)",
"regex 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
"same-file 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"thread_local 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"walkdir 2.2.7 (registry+https://github.com/rust-lang/crates.io-index)",
"winapi-util 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo to ffab51954ec32d55631c37a8730bb24915fc090b https://github.com/rust-lang/cargo/pull/4123 added the [patch] section of the manifest
2017-07-18 23:26:55 +02:00
]
Update cargo
2018-12-03 02:33:20 +01:00
[[package]]
name = "im-rc"
Update Cargo.lock
2019-02-18 10:32:58 +01:00
version = "12.3.0"
Update cargo
2018-12-03 02:33:20 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"rustc_version 0.2.3 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo
2018-12-03 02:33:20 +01:00
"typenum 1.10.0 (registry+https://github.com/rust-lang/crates.io-index)",
]
Update to the oxidized rust-installer
2017-05-09 00:01:13 +02:00
[[package]]
name = "installer"
version = "0.0.0"
dependencies = [
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"clap 2.32.0 (registry+https://github.com/rust-lang/crates.io-index)",
Add lldb to the build 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 dependency.
2018-07-03 20:24:24 +02:00
"error-chain 0.12.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"flate2 1.0.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS
2018-12-10 08:58:08 +01:00
"lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
Bump to 1.27.0 Also update some `Cargo.lock` dependencies, finishing up some final steps of our [release process]! This doesn't update the bootstrap compiler just yet but that will come in a follow-up PR. [release process]: https://forge.rust-lang.org/release-process.html
2018-04-02 17:43:55 +02:00
"rayon 1.0.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"tar 0.4.20 (registry+https://github.com/rust-lang/crates.io-index)",
"walkdir 2.2.7 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"xz2 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)",
Update to the oxidized rust-installer
2017-05-09 00:01:13 +02:00
]
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
[[package]]
name = "iovec"
version = "0.1.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
"winapi 0.2.8 (registry+https://github.com/rust-lang/crates.io-index)",
]
update mdbook to 0.1.2 and improve printing of errors
2018-01-25 18:32:25 +01:00
[[package]]
name = "is-match"
version = "0.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
[[package]]
name = "itertools"
Bump to 1.27.0 Also update some `Cargo.lock` dependencies, finishing up some final steps of our [release process]! This doesn't update the bootstrap compiler just yet but that will come in a follow-up PR. [release process]: https://forge.rust-lang.org/release-process.html
2018-04-02 17:43:55 +02:00
version = "0.7.8"
update mdbook to 0.1.2 and improve printing of errors
2018-01-25 18:32:25 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Bump to 1.27.0 Also update some `Cargo.lock` dependencies, finishing up some final steps of our [release process]! This doesn't update the bootstrap compiler just yet but that will come in a follow-up PR. [release process]: https://forge.rust-lang.org/release-process.html
2018-04-02 17:43:55 +02:00
"either 1.5.0 (registry+https://github.com/rust-lang/crates.io-index)",
update mdbook to 0.1.2 and improve printing of errors
2018-01-25 18:32:25 +01:00
]
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
[[package]]
name = "itertools"
version = "0.8.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"either 1.5.0 (registry+https://github.com/rust-lang/crates.io-index)",
]
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
[[package]]
Update Cargo Brings in some perf improvements!
2017-06-05 18:36:48 +02:00
name = "itoa"
Update Cargo's submodule Bring in a few updates and fixes, mostly a standard update.
2018-09-28 20:27:30 +02:00
version = "0.4.3"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Use `jemalloc-sys` on Linux and OSX compilers 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-21 04:15:06 +02:00
[[package]]
name = "jemalloc-sys"
Update Cargo.lock
2019-03-26 11:29:21 +01:00
version = "0.3.0"
Use `jemalloc-sys` on Linux and OSX compilers 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-21 04:15:06 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update cc crate to include Armv8-M changes
2019-01-09 15:51:22 +01:00
"cc 1.0.28 (registry+https://github.com/rust-lang/crates.io-index)",
Use `jemalloc-sys` on Linux and OSX compilers 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-21 04:15:06 +02:00
"fs_extra 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Use `jemalloc-sys` on Linux and OSX compilers 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-21 04:15:06 +02:00
]
Update dependencies In order to update mdbook, we have to update other stuff too.
2017-02-20 01:20:57 +01:00
[[package]]
Update Cargo Brings in some perf improvements!
2017-06-05 18:36:48 +02:00
name = "jobserver"
Update cargo
2019-03-29 04:13:13 +01:00
version = "0.1.13"
Update dependencies In order to update mdbook, we have to update other stuff too.
2017-02-20 01:20:57 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Update Cargo Brings in some perf improvements!
2017-06-05 18:36:48 +02:00
dependencies = [
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
"rand 0.6.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo Brings in some perf improvements!
2017-06-05 18:36:48 +02:00
]
Update dependencies In order to update mdbook, we have to update other stuff too.
2017-02-20 01:20:57 +01:00
Bump serde_json 1.0.24 -> 1.0.25 This fixes 'cannot find macro `json_internal!` in this scope' RLS compilation error in Rust CI, presumably due to a local macro fix in serde_json 1.0.25 (https://github.com/serde-rs/json/commit/e40cbad70b39a0dd7975be8e5ad9018e2d45f791)
2018-08-25 18:17:55 +02:00
[[package]]
name = "json"
version = "0.11.13"
source = "registry+https://github.com/rust-lang/crates.io-index"
Point RLS submodule at a branch with required changes And cargo update
2017-07-19 03:32:12 +02:00
[[package]]
name = "jsonrpc-core"
submodule: update rls from c9d25b667a to f331ff7
2019-02-03 01:48:18 +01:00
version = "10.0.1"
Point RLS submodule at a branch with required changes And cargo update
2017-07-19 03:32:12 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"futures 0.1.21 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock
2019-01-10 13:42:14 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo, rls, miri
2018-12-17 19:23:04 +01:00
"serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"serde_derive 1.0.81 (registry+https://github.com/rust-lang/crates.io-index)",
"serde_json 1.0.33 (registry+https://github.com/rust-lang/crates.io-index)",
Point RLS submodule at a branch with required changes And cargo update
2017-07-19 03:32:12 +02:00
]
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
[[package]]
name = "kernel32-sys"
version = "0.2.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"winapi 0.2.8 (registry+https://github.com/rust-lang/crates.io-index)",
"winapi-build 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "lazy_static"
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
version = "0.2.11"
source = "registry+https://github.com/rust-lang/crates.io-index"
Update Cargo and its dependencies Just a routine update!
2017-12-10 18:42:49 +01:00
[[package]]
name = "lazy_static"
Update RLS
2018-12-10 08:58:08 +01:00
version = "1.2.0"
Update Cargo and its dependencies Just a routine update!
2017-12-10 18:42:49 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Update Cargo submodule Required moving all fulldeps tests depending on `rand` to different locations as now there's multiple `rand` crates that can't be implicitly linked against.
2018-02-26 18:07:16 +01:00
[[package]]
name = "lazycell"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "1.2.1"
Update Cargo submodule Required moving all fulldeps tests depending on `rand` to different locations as now there's multiple `rand` crates that can't be implicitly linked against.
2018-02-26 18:07:16 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
[[package]]
name = "libc"
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
version = "0.2.51"
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
std: Depend directly on crates.io crates 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-11-20 06:52:50 +01:00
dependencies = [
"rustc-std-workspace-core 1.0.0",
]
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
[[package]]
name = "libgit2-sys"
Update cargo, rls, miri
2018-12-17 19:23:04 +01:00
version = "0.7.11"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update cc crate to include Armv8-M changes
2019-01-09 15:51:22 +01:00
"cc 1.0.28 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Hopefully a relatively routine update!
2018-11-09 21:55:25 +01:00
"curl-sys 0.4.15 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update some `*-sys` dependencies of Cargo/RLS This is intended to help solve #54206 on nightly where the RLS on MinGW is having build issues with accidentally building a `curl` library which links to pthread symbols on Windows (where it should use native mutex locking instead). The build system for these `*-sys` crates have all been rewritten to be based on `cc` to bypass native build systems and platform detection to make sure we configure them correctly.
2018-09-17 18:52:02 +02:00
"libssh2-sys 0.2.11 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"libz-sys 1.0.25 (registry+https://github.com/rust-lang/crates.io-index)",
Upgrade openssl and openssl-sys
2019-01-02 11:06:36 +01:00
"openssl-sys 0.9.40 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"pkg-config 0.3.14 (registry+https://github.com/rust-lang/crates.io-index)",
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
]
Update Cargo This commit brings in a few Cargo updates * Updates Cargo with experimental HTTP/2 support - a post on the forums will be made about testing this when available. * Bumps Cargo's own version number
2018-09-20 23:37:53 +02:00
[[package]]
name = "libnghttp2-sys"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "0.1.1"
Update Cargo This commit brings in a few Cargo updates * Updates Cargo with experimental HTTP/2 support - a post on the forums will be made about testing this when available. * Bumps Cargo's own version number
2018-09-20 23:37:53 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update cc crate to include Armv8-M changes
2019-01-09 15:51:22 +01:00
"cc 1.0.28 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo This commit brings in a few Cargo updates * Updates Cargo with experimental HTTP/2 support - a post on the forums will be made about testing this when available. * Bumps Cargo's own version number
2018-09-20 23:37:53 +02:00
]
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
[[package]]
name = "libssh2-sys"
Update some `*-sys` dependencies of Cargo/RLS This is intended to help solve #54206 on nightly where the RLS on MinGW is having build issues with accidentally building a `curl` library which links to pthread symbols on Windows (where it should use native mutex locking instead). The build system for these `*-sys` crates have all been rewritten to be based on `cc` to bypass native build systems and platform detection to make sure we configure them correctly.
2018-09-17 18:52:02 +02:00
version = "0.2.11"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update cc crate to include Armv8-M changes
2019-01-09 15:51:22 +01:00
"cc 1.0.28 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"libz-sys 1.0.25 (registry+https://github.com/rust-lang/crates.io-index)",
Upgrade openssl and openssl-sys
2019-01-02 11:06:36 +01:00
"openssl-sys 0.9.40 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"pkg-config 0.3.14 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"vcpkg 0.2.6 (registry+https://github.com/rust-lang/crates.io-index)",
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
]
Directly reference the roadmap upstream
2019-03-04 18:29:23 +01:00
[[package]]
name = "libtest"
version = "0.0.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"getopts 0.2.17 (registry+https://github.com/rust-lang/crates.io-index)",
"rustc_term 0.0.1 (registry+https://github.com/rust-lang/crates.io-index)",
]
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
[[package]]
name = "libz-sys"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "1.0.25"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update cc crate to include Armv8-M changes
2019-01-09 15:51:22 +01:00
"cc 1.0.28 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"pkg-config 0.3.14 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"vcpkg 0.2.6 (registry+https://github.com/rust-lang/crates.io-index)",
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
]
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
[[package]]
name = "linkchecker"
version = "0.1.0"
Breaking change upgrades
2018-08-05 00:24:39 +02:00
[[package]]
name = "lock_api"
version = "0.1.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"owning_ref 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)",
"scopeguard 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)",
]
Update crates and submodules to pull doc fixes Update `rand` crate to `0.3.19`. Update `log` crate to `0.3.9` and `0.4.1`. Update `parking_lot_core` crate to `0.2.9`. Upgrade all flate2 dependencies to `1.0.1`. - Update `rust-installer` submodule.
2017-12-29 11:24:38 +01:00
[[package]]
name = "log"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "0.4.6"
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Update crates and submodules to pull doc fixes Update `rand` crate to `0.3.19`. Update `log` crate to `0.3.9` and `0.4.1`. Update `parking_lot_core` crate to `0.2.9`. Upgrade all flate2 dependencies to `1.0.1`. - Update `rust-installer` submodule.
2017-12-29 11:24:38 +01:00
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"cfg-if 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update crates and submodules to pull doc fixes Update `rand` crate to `0.3.19`. Update `log` crate to `0.3.9` and `0.4.1`. Update `parking_lot_core` crate to `0.2.9`. Upgrade all flate2 dependencies to `1.0.1`. - Update `rust-installer` submodule.
2017-12-29 11:24:38 +01:00
]
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
Adjust imports to librustc::mir::interpret
2017-09-18 16:18:23 +02:00
[[package]]
name = "log_settings"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
version = "0.1.2"
Adjust imports to librustc::mir::interpret
2017-09-18 16:18:23 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update RLS
2018-12-10 08:58:08 +01:00
"lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
Adjust imports to librustc::mir::interpret
2017-09-18 16:18:23 +02:00
]
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
[[package]]
name = "lsp-codec"
Update cargo, rls
2019-03-04 22:18:44 +01:00
version = "0.1.2"
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"bytes 0.4.11 (registry+https://github.com/rust-lang/crates.io-index)",
"serde_json 1.0.33 (registry+https://github.com/rust-lang/crates.io-index)",
"tokio-codec 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "lsp-types"
Update Cargo.lock
2019-02-18 10:32:58 +01:00
version = "0.55.4"
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"bitflags 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)",
"num-derive 0.2.3 (registry+https://github.com/rust-lang/crates.io-index)",
"num-traits 0.2.6 (registry+https://github.com/rust-lang/crates.io-index)",
"serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)",
"serde_derive 1.0.81 (registry+https://github.com/rust-lang/crates.io-index)",
"serde_json 1.0.33 (registry+https://github.com/rust-lang/crates.io-index)",
"url 1.7.2 (registry+https://github.com/rust-lang/crates.io-index)",
"url_serde 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
]
Update to the oxidized rust-installer
2017-05-09 00:01:13 +02:00
[[package]]
name = "lzma-sys"
Dedupe filetime
2018-07-06 22:52:40 +02:00
version = "0.1.10"
Update to the oxidized rust-installer
2017-05-09 00:01:13 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update cc crate to include Armv8-M changes
2019-01-09 15:51:22 +01:00
"cc 1.0.28 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"filetime 0.2.4 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"pkg-config 0.3.14 (registry+https://github.com/rust-lang/crates.io-index)",
Update to the oxidized rust-installer
2017-05-09 00:01:13 +02:00
]
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
[[package]]
name = "mac"
version = "0.1.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
Fix links' color
2018-08-15 15:07:07 +02:00
[[package]]
name = "macro-utils"
version = "0.1.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
[[package]]
name = "maplit"
version = "1.0.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
[[package]]
name = "markup5ever"
version = "0.7.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"phf 0.7.22 (registry+https://github.com/rust-lang/crates.io-index)",
"phf_codegen 0.7.22 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo, rls, miri
2018-12-17 19:23:04 +01:00
"serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"serde_derive 1.0.81 (registry+https://github.com/rust-lang/crates.io-index)",
"serde_json 1.0.33 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"string_cache 0.7.3 (registry+https://github.com/rust-lang/crates.io-index)",
Update string_cache_codegen to 0.4.2
2019-02-26 12:06:31 +01:00
"string_cache_codegen 0.4.2 (registry+https://github.com/rust-lang/crates.io-index)",
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
"tendril 0.4.0 (registry+https://github.com/rust-lang/crates.io-index)",
]
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
[[package]]
name = "matches"
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
version = "0.1.8"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
[[package]]
name = "mdbook"
Update MDBook
2018-04-21 23:06:13 +02:00
version = "0.1.7"
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
"ammonia 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"chrono 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"clap 2.32.0 (registry+https://github.com/rust-lang/crates.io-index)",
Reduce the numbers of syn versions compiled from 4 to 2 The last remaining one comes from mdbook. Unfortunately updating it breaks everything
2018-12-08 15:11:47 +01:00
"elasticlunr-rs 2.3.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"env_logger 0.5.13 (registry+https://github.com/rust-lang/crates.io-index)",
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
"error-chain 0.11.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"handlebars 0.32.4 (registry+https://github.com/rust-lang/crates.io-index)",
Bump to 1.27.0 Also update some `Cargo.lock` dependencies, finishing up some final steps of our [release process]! This doesn't update the bootstrap compiler just yet but that will come in a follow-up PR. [release process]: https://forge.rust-lang.org/release-process.html
2018-04-02 17:43:55 +02:00
"itertools 0.7.8 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS
2018-12-10 08:58:08 +01:00
"lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
"memchr 2.1.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update some minor dependencies
2017-09-28 00:37:02 +02:00
"open 1.2.1 (registry+https://github.com/rust-lang/crates.io-index)",
bump pulldown
2018-02-18 22:33:56 +01:00
"pulldown-cmark 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"regex 0.2.11 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo, rls, miri
2018-12-17 19:23:04 +01:00
"serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"serde_derive 1.0.81 (registry+https://github.com/rust-lang/crates.io-index)",
"serde_json 1.0.33 (registry+https://github.com/rust-lang/crates.io-index)",
update mdbook to 0.1.2 and improve printing of errors
2018-01-25 18:32:25 +01:00
"shlex 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"tempfile 3.0.5 (registry+https://github.com/rust-lang/crates.io-index)",
"toml 0.4.10 (registry+https://github.com/rust-lang/crates.io-index)",
update mdbook to 0.1.2 and improve printing of errors
2018-01-25 18:32:25 +01:00
"toml-query 0.6.0 (registry+https://github.com/rust-lang/crates.io-index)",
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
]
Update to newer version of mdbook(2)
2019-01-19 03:39:37 +01:00
[[package]]
name = "mdbook"
version = "0.2.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"ammonia 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
"chrono 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
"clap 2.32.0 (registry+https://github.com/rust-lang/crates.io-index)",
"elasticlunr-rs 2.3.4 (registry+https://github.com/rust-lang/crates.io-index)",
"env_logger 0.5.13 (registry+https://github.com/rust-lang/crates.io-index)",
"error-chain 0.12.0 (registry+https://github.com/rust-lang/crates.io-index)",
"handlebars 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
"itertools 0.7.8 (registry+https://github.com/rust-lang/crates.io-index)",
"lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
"memchr 2.1.1 (registry+https://github.com/rust-lang/crates.io-index)",
"open 1.2.1 (registry+https://github.com/rust-lang/crates.io-index)",
"pulldown-cmark 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)",
"regex 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
"serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)",
"serde_derive 1.0.81 (registry+https://github.com/rust-lang/crates.io-index)",
"serde_json 1.0.33 (registry+https://github.com/rust-lang/crates.io-index)",
"shlex 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)",
"tempfile 3.0.5 (registry+https://github.com/rust-lang/crates.io-index)",
"toml 0.4.10 (registry+https://github.com/rust-lang/crates.io-index)",
"toml-query 0.7.0 (registry+https://github.com/rust-lang/crates.io-index)",
]
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
[[package]]
name = "memchr"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "2.1.1"
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"cfg-if 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"version_check 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)",
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
]
Always add all modules to the global ThinLTO module analysis when compiling incrementally.
2018-08-31 15:18:08 +02:00
[[package]]
name = "memmap"
version = "0.6.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
Always add all modules to the global ThinLTO module analysis when compiling incrementally.
2018-08-31 15:18:08 +02:00
]
Update RLS
2018-02-26 04:15:45 +01:00
[[package]]
name = "memoffset"
version = "0.2.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
Add minification process
2018-05-11 00:02:05 +02:00
[[package]]
name = "minifier"
Update minifier version
2019-01-25 00:07:08 +01:00
version = "0.0.28"
Add minification process
2018-05-11 00:02:05 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Fix links' color
2018-08-15 15:07:07 +02:00
"macro-utils 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)",
Add minification process
2018-05-11 00:02:05 +02:00
]
Update to the oxidized rust-installer
2017-05-09 00:01:13 +02:00
[[package]]
name = "miniz-sys"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "0.1.11"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update cc crate to include Armv8-M changes
2019-01-09 15:51:22 +01:00
"cc 1.0.28 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
]
[[package]]
name = "miniz_oxide"
version = "0.2.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"adler32 1.0.3 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "miniz_oxide_c_api"
version = "0.2.0"
Update to the oxidized rust-installer
2017-05-09 00:01:13 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update cc crate to include Armv8-M changes
2019-01-09 15:51:22 +01:00
"cc 1.0.28 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"crc 1.8.1 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"miniz_oxide 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
]
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
[[package]]
name = "mio"
version = "0.6.16"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"fuchsia-zircon 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)",
"fuchsia-zircon-sys 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)",
"iovec 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)",
"kernel32-sys 0.2.2 (registry+https://github.com/rust-lang/crates.io-index)",
"lazycell 1.2.1 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
"miow 0.2.1 (registry+https://github.com/rust-lang/crates.io-index)",
"net2 0.2.33 (registry+https://github.com/rust-lang/crates.io-index)",
"slab 0.4.2 (registry+https://github.com/rust-lang/crates.io-index)",
"winapi 0.2.8 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "mio-named-pipes"
version = "0.1.6"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
"mio 0.6.16 (registry+https://github.com/rust-lang/crates.io-index)",
"miow 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)",
"winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "mio-uds"
version = "0.6.7"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"iovec 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
"mio 0.6.16 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "miow"
version = "0.2.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"kernel32-sys 0.2.2 (registry+https://github.com/rust-lang/crates.io-index)",
"net2 0.2.33 (registry+https://github.com/rust-lang/crates.io-index)",
"winapi 0.2.8 (registry+https://github.com/rust-lang/crates.io-index)",
"ws2_32-sys 0.2.1 (registry+https://github.com/rust-lang/crates.io-index)",
]
Update cargo lock
2018-03-07 08:39:55 +01:00
[[package]]
name = "miow"
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
version = "0.3.3"
Update cargo lock
2018-03-07 08:39:55 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"socket2 0.3.8 (registry+https://github.com/rust-lang/crates.io-index)",
"winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo lock
2018-03-07 08:39:55 +01:00
]
cargo update and add miri as the rustc workspace member.
2017-12-15 20:41:58 +01:00
[[package]]
name = "miri"
version = "0.1.0"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"byteorder 1.2.7 (registry+https://github.com/rust-lang/crates.io-index)",
submodules: update clippy from d8b42690 to f5d868c9 Fixes clippy toolstate. Changes: ```` rustup https://github.com/rust-lang/rust/pull/55852/ Fix "too" -> "foo" typo in format.rs Fix `use_self` violation Fix wrong suggestion for `redundant_closure_call` Check for common metadata Fix `use_self` false positive on `use` statements Fix `use_self` false positive Remove `+` from `has_unary_equivalent` Fix dogfood Update println! formatting Fix false positive in check mode caused by `gen_deprecated` RIIR update lints: Add check mode (update_lints.py rewrite complete) changed into_iter to iter and fixed a lint check Fix `collapsible_if` error Fix `possible_missing_comma` false positives format code fix comment spacing change single char str to char add lint to lintarray macro Revert "small fix" small fix added float support for mistyped literal lints tmp progress ````
2018-11-14 14:49:40 +01:00
"cargo_metadata 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)",
update miri
2018-07-13 10:34:50 +02:00
"colored 1.6.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Clippy
2019-03-03 14:48:03 +01:00
"compiletest_rs 0.3.19 (registry+https://github.com/rust-lang/crates.io-index)",
update miri
2018-11-28 21:22:45 +01:00
"directories 1.0.2 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock
2019-01-10 13:42:14 +01:00
"env_logger 0.6.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock
2019-01-10 13:42:14 +01:00
"rustc-workspace-hack 1.0.0",
"rustc_version 0.2.3 (registry+https://github.com/rust-lang/crates.io-index)",
update Cargo.lock and miri URL
2019-02-17 12:39:40 +01:00
"shell-escape 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)",
update vergen
2018-12-07 10:12:01 +01:00
"vergen 3.0.4 (registry+https://github.com/rust-lang/crates.io-index)",
cargo update and add miri as the rustc workspace member.
2017-12-15 20:41:58 +01:00
]
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
[[package]]
name = "net2"
version = "0.2.33"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"cfg-if 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
"winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
]
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
[[package]]
name = "new_debug_unreachable"
version = "1.0.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"unreachable 1.0.0 (registry+https://github.com/rust-lang/crates.io-index)",
]
Update RLS
2018-02-26 04:15:45 +01:00
[[package]]
name = "nodrop"
version = "0.1.12"
source = "registry+https://github.com/rust-lang/crates.io-index"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
[[package]]
Update clippy and rls
2018-07-15 00:01:24 +02:00
name = "num-derive"
Reduce the numbers of syn versions compiled from 4 to 2 The last remaining one comes from mdbook. Unfortunately updating it breaks everything
2018-12-08 15:11:47 +01:00
version = "0.2.3"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"num-traits 0.2.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS and Rustfmt
2018-11-19 05:21:10 +01:00
"proc-macro2 0.4.24 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"quote 0.6.10 (registry+https://github.com/rust-lang/crates.io-index)",
"syn 0.15.22 (registry+https://github.com/rust-lang/crates.io-index)",
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
]
[[package]]
Update clippy and rls
2018-07-15 00:01:24 +02:00
name = "num-integer"
version = "0.1.39"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"num-traits 0.2.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update to the oxidized rust-installer
2017-05-09 00:01:13 +02:00
]
Update dependencies In order to update mdbook, we have to update other stuff too.
2017-02-20 01:20:57 +01:00
[[package]]
name = "num-traits"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "0.2.6"
Update dependencies In order to update mdbook, we have to update other stuff too.
2017-02-20 01:20:57 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
[[package]]
name = "num_cpus"
Update Cargo and its dependencies This'll probably have a bunch of build errors, so let's try and head those off and find them sooner rather than later!
2018-01-08 22:56:22 +01:00
version = "1.8.0"
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
]
Update dependencies In order to update mdbook, we have to update other stuff too.
2017-02-20 01:20:57 +01:00
[[package]]
name = "open"
Update some minor dependencies
2017-09-28 00:37:02 +02:00
version = "1.2.1"
Update dependencies In order to update mdbook, we have to update other stuff too.
2017-02-20 01:20:57 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
[[package]]
name = "opener"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "0.3.2"
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update cargo
2019-02-03 23:42:29 +01:00
"failure 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)",
"failure_derive 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
]
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
[[package]]
name = "openssl"
Upgrade openssl and openssl-sys
2019-01-02 11:06:36 +01:00
version = "0.10.16"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"bitflags 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"cfg-if 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
"foreign-types 0.3.2 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS
2018-12-10 08:58:08 +01:00
"lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Upgrade openssl and openssl-sys
2019-01-02 11:06:36 +01:00
"openssl-sys 0.9.40 (registry+https://github.com/rust-lang/crates.io-index)",
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
]
[[package]]
name = "openssl-probe"
Update Cargo and its dependencies Just a routine update!
2017-12-10 18:42:49 +01:00
version = "0.1.2"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Update cargo
2018-08-14 23:27:26 +02:00
[[package]]
name = "openssl-src"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "111.1.0+1.1.1a"
Update cargo
2018-08-14 23:27:26 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update cc crate to include Armv8-M changes
2019-01-09 15:51:22 +01:00
"cc 1.0.28 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo
2018-08-14 23:27:26 +02:00
]
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
[[package]]
name = "openssl-sys"
Upgrade openssl and openssl-sys
2019-01-02 11:06:36 +01:00
version = "0.9.40"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update cc crate to include Armv8-M changes
2019-01-09 15:51:22 +01:00
"cc 1.0.28 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"openssl-src 111.1.0+1.1.1a (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"pkg-config 0.3.14 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"vcpkg 0.2.6 (registry+https://github.com/rust-lang/crates.io-index)",
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
]
Implement generating graphs of the build steps
2018-03-27 12:44:33 +02:00
[[package]]
name = "ordermap"
version = "0.3.5"
source = "registry+https://github.com/rust-lang/crates.io-index"
Update RLS, Rustfmt, Cargo, and Clippy
2018-07-06 02:34:00 +02:00
[[package]]
name = "ordslice"
version = "0.3.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
Remove rustc_llvm dependency from rustc_metadata Move the code for loading metadata from rlibs and dylibs from rustc_metadata into rustc_trans, and introduce a trait to avoid introducing a direct dependency on rustc_trans. This means rustc_metadata is no longer rebuilt when LLVM changes.
2017-04-26 23:22:45 +02:00
[[package]]
name = "owning_ref"
version = "0.3.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"stable_deref_trait 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
Remove rustc_llvm dependency from rustc_metadata Move the code for loading metadata from rlibs and dylibs from rustc_metadata into rustc_trans, and introduce a trait to avoid introducing a direct dependency on rustc_trans. This means rustc_metadata is no longer rebuilt when LLVM changes.
2017-04-26 23:22:45 +02:00
]
Update RLS and Rustfmt Closes #56261
2018-12-01 11:36:32 +01:00
[[package]]
name = "packed_simd"
version = "0.3.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"cfg-if 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS and Rustfmt Closes #56261
2018-12-01 11:36:32 +01:00
]
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
[[package]]
name = "panic_abort"
version = "0.0.0"
dependencies = [
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"compiler_builtins 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"core 0.0.0",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
]
[[package]]
name = "panic_unwind"
version = "0.0.0"
dependencies = [
"alloc 0.0.0",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"compiler_builtins 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"core 0.0.0",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"unwind 0.0.0",
]
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
[[package]]
name = "parking_lot"
version = "0.7.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"lock_api 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)",
"parking_lot_core 0.4.0 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "parking_lot_core"
version = "0.4.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
"rand 0.6.1 (registry+https://github.com/rust-lang/crates.io-index)",
"rustc_version 0.2.3 (registry+https://github.com/rust-lang/crates.io-index)",
"smallvec 0.6.7 (registry+https://github.com/rust-lang/crates.io-index)",
"winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
]
Update cargo/rls submodules and dependencies Brings in a few regression fixes on the Cargo side, updates the rls to work with the newer Cargo, and also updates other crates.io dependencies to pull in various bug fixes and such.
2017-06-15 04:33:06 +02:00
[[package]]
name = "percent-encoding"
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
version = "1.0.1"
Update cargo/rls submodules and dependencies Brings in a few regression fixes on the Cargo side, updates the rls to work with the newer Cargo, and also updates other crates.io dependencies to pull in various bug fixes and such.
2017-06-15 04:33:06 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
[[package]]
name = "pest"
Bump to 1.27.0 Also update some `Cargo.lock` dependencies, finishing up some final steps of our [release process]! This doesn't update the bootstrap compiler just yet but that will come in a follow-up PR. [release process]: https://forge.rust-lang.org/release-process.html
2018-04-02 17:43:55 +02:00
version = "1.0.6"
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Update to newer version of mdbook(2)
2019-01-19 03:39:37 +01:00
[[package]]
name = "pest"
version = "2.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"ucd-trie 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)",
]
Bump to 1.27.0 Also update some `Cargo.lock` dependencies, finishing up some final steps of our [release process]! This doesn't update the bootstrap compiler just yet but that will come in a follow-up PR. [release process]: https://forge.rust-lang.org/release-process.html
2018-04-02 17:43:55 +02:00
[[package]]
name = "pest_derive"
Reduce the numbers of syn versions compiled from 4 to 2 The last remaining one comes from mdbook. Unfortunately updating it breaks everything
2018-12-08 15:11:47 +01:00
version = "1.0.8"
Bump to 1.27.0 Also update some `Cargo.lock` dependencies, finishing up some final steps of our [release process]! This doesn't update the bootstrap compiler just yet but that will come in a follow-up PR. [release process]: https://forge.rust-lang.org/release-process.html
2018-04-02 17:43:55 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"pest 1.0.6 (registry+https://github.com/rust-lang/crates.io-index)",
"quote 0.3.15 (registry+https://github.com/rust-lang/crates.io-index)",
"syn 0.11.11 (registry+https://github.com/rust-lang/crates.io-index)",
]
Update to newer version of mdbook(2)
2019-01-19 03:39:37 +01:00
[[package]]
name = "pest_derive"
version = "2.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"pest 2.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
"pest_generator 2.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "pest_generator"
version = "2.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"pest 2.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
"pest_meta 2.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
"proc-macro2 0.4.24 (registry+https://github.com/rust-lang/crates.io-index)",
"quote 0.6.10 (registry+https://github.com/rust-lang/crates.io-index)",
"syn 0.15.22 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "pest_meta"
version = "2.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"maplit 1.0.1 (registry+https://github.com/rust-lang/crates.io-index)",
"pest 2.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
"sha-1 0.7.0 (registry+https://github.com/rust-lang/crates.io-index)",
]
Implement generating graphs of the build steps
2018-03-27 12:44:33 +02:00
[[package]]
name = "petgraph"
Update `petgraph` dependency to 0.4.13 This fixes building `bootstrap` using a local Rust nightly.
2018-09-08 08:04:29 +02:00
version = "0.4.13"
Implement generating graphs of the build steps
2018-03-27 12:44:33 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"fixedbitset 0.1.9 (registry+https://github.com/rust-lang/crates.io-index)",
"ordermap 0.3.5 (registry+https://github.com/rust-lang/crates.io-index)",
]
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
[[package]]
name = "phf"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
version = "0.7.22"
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"phf_shared 0.7.22 (registry+https://github.com/rust-lang/crates.io-index)",
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
]
[[package]]
name = "phf_codegen"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
version = "0.7.22"
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"phf_generator 0.7.22 (registry+https://github.com/rust-lang/crates.io-index)",
"phf_shared 0.7.22 (registry+https://github.com/rust-lang/crates.io-index)",
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
]
[[package]]
name = "phf_generator"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
version = "0.7.22"
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"phf_shared 0.7.22 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"rand 0.4.3 (registry+https://github.com/rust-lang/crates.io-index)",
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
]
[[package]]
name = "phf_shared"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
version = "0.7.22"
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"siphasher 0.2.2 (registry+https://github.com/rust-lang/crates.io-index)",
]
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
[[package]]
name = "pkg-config"
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
version = "0.3.14"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Use AllFacts from polonius-engine
2018-05-24 23:52:01 +02:00
[[package]]
name = "polonius-engine"
adopt polonius-engine 0.6.2 Also datafrog 2.0.1, which works around a rustdoc bug
2019-01-02 20:45:22 +01:00
version = "0.6.2"
Use AllFacts from polonius-engine
2018-05-24 23:52:01 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
bump polonius engine
2018-05-29 13:52:51 +02:00
dependencies = [
adopt polonius-engine 0.6.2 Also datafrog 2.0.1, which works around a rustdoc bug
2019-01-02 20:45:22 +01:00
"datafrog 2.0.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
WIP fix rustc-hash cargo.lock entry for polonius-engine
2018-05-29 15:36:45 +02:00
"rustc-hash 1.0.1 (registry+https://github.com/rust-lang/crates.io-index)",
bump polonius engine
2018-05-29 13:52:51 +02:00
]
Use AllFacts from polonius-engine
2018-05-24 23:52:01 +02:00
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
[[package]]
name = "precomputed-hash"
version = "0.1.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
Add tests to rustbuild In order to run tests, previous commits have cfg'd out various parts of rustbuild. Generally speaking, these are filesystem-related operations and process-spawning related parts. Then, rustbuild is run "as normal" and the various steps that where run are retrieved from the cache and checked against the expected results. Note that this means that the current implementation primarily tests "what" we build, but doesn't actually test that what we build *will* build. In other words, it doesn't do any form of dependency verification for any crate. This is possible to implement, but is considered future work. This implementation strives to cfg out as little code as possible; it also does not currently test anywhere near all of rustbuild. The current tests are also not checked for "correctness," rather, they simply represent what we do as of this commit, which may be wrong. Test cases are drawn from the old implementation of rustbuild, though the expected results may vary.
2018-03-10 15:03:06 +01:00
[[package]]
name = "pretty_assertions"
version = "0.5.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"ansi_term 0.11.0 (registry+https://github.com/rust-lang/crates.io-index)",
"difference 2.0.0 (registry+https://github.com/rust-lang/crates.io-index)",
]
Update cargo
2018-12-03 02:33:20 +01:00
[[package]]
name = "pretty_env_logger"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "0.3.0"
Update cargo
2018-12-03 02:33:20 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"chrono 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
"env_logger 0.6.0 (registry+https://github.com/rust-lang/crates.io-index)",
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo
2018-12-03 02:33:20 +01:00
]
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
[[package]]
name = "proc-macro2"
Update RLS and Rustfmt
2018-11-19 05:21:10 +01:00
version = "0.4.24"
Bump to 1.27.0 Also update some `Cargo.lock` dependencies, finishing up some final steps of our [release process]! This doesn't update the bootstrap compiler just yet but that will come in a follow-up PR. [release process]: https://forge.rust-lang.org/release-process.html
2018-04-02 17:43:55 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"unicode-xid 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
]
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
[[package]]
name = "proc_macro"
version = "0.0.0"
Add profiling support, through the rustc -Z profile flag. When -Z profile is passed, the GCDAProfiling LLVM pass is added to the pipeline, which uses debug information to instrument the IR. After compiling with -Z profile, the $(OUT_DIR)/$(CRATE_NAME).gcno file is created, containing initial profiling information. After running the program built, the $(OUT_DIR)/$(CRATE_NAME).gcda file is created, containing branch counters. The created *.gcno and *.gcda files can be processed using the "llvm-cov gcov" and "lcov" tools. The profiling data LLVM generates does not faithfully follow the GCC's format for *.gcno and *.gcda files, and so it will probably not work with other tools (such as gcov itself) that consume these files.
2017-02-13 10:57:50 +01:00
[[package]]
name = "profiler_builtins"
version = "0.0.0"
dependencies = [
lock after rebase
2019-01-17 11:22:48 +01:00
"cc 1.0.28 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"compiler_builtins 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)",
Add profiling support, through the rustc -Z profile flag. When -Z profile is passed, the GCDAProfiling LLVM pass is added to the pipeline, which uses debug information to instrument the IR. After compiling with -Z profile, the $(OUT_DIR)/$(CRATE_NAME).gcno file is created, containing initial profiling information. After running the program built, the $(OUT_DIR)/$(CRATE_NAME).gcda file is created, containing branch counters. The created *.gcno and *.gcda files can be processed using the "llvm-cov gcov" and "lcov" tools. The profiling data LLVM generates does not faithfully follow the GCC's format for *.gcno and *.gcda files, and so it will probably not work with other tools (such as gcov itself) that consume these files.
2017-02-13 10:57:50 +01:00
"core 0.0.0",
Merge branch 'profiling' of github.com:whitequark/rust into profiling
2017-06-04 16:54:39 +02:00
]
Update Cargo's submodule Bring in a few updates and fixes, mostly a standard update.
2018-09-28 20:27:30 +02:00
[[package]]
name = "proptest"
Update cargo
2019-03-29 04:13:13 +01:00
version = "0.9.2"
Update Cargo's submodule Bring in a few updates and fixes, mostly a standard update.
2018-09-28 20:27:30 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"bit-set 0.5.0 (registry+https://github.com/rust-lang/crates.io-index)",
"bitflags 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"byteorder 1.2.7 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS
2018-12-10 08:58:08 +01:00
"lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"num-traits 0.2.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo's submodule Bring in a few updates and fixes, mostly a standard update.
2018-09-28 20:27:30 +02:00
"quick-error 1.2.2 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo
2019-03-29 04:13:13 +01:00
"rand 0.6.1 (registry+https://github.com/rust-lang/crates.io-index)",
"rand_chacha 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
"rand_xorshift 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"regex-syntax 0.6.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo's submodule Bring in a few updates and fixes, mostly a standard update.
2018-09-28 20:27:30 +02:00
"rusty-fork 0.2.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"tempfile 3.0.5 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo's submodule Bring in a few updates and fixes, mostly a standard update.
2018-09-28 20:27:30 +02:00
]
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
[[package]]
name = "pulldown-cmark"
bump pulldown
2018-02-18 22:33:56 +01:00
version = "0.1.2"
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"bitflags 0.9.1 (registry+https://github.com/rust-lang/crates.io-index)",
Bump to 1.27.0 Also update some `Cargo.lock` dependencies, finishing up some final steps of our [release process]! This doesn't update the bootstrap compiler just yet but that will come in a follow-up PR. [release process]: https://forge.rust-lang.org/release-process.html
2018-04-02 17:43:55 +02:00
"getopts 0.2.17 (registry+https://github.com/rust-lang/crates.io-index)",
Update pulldown version after fix merged
2017-03-12 20:28:36 +01:00
]
submodules: update clippy from 2f6881c6 to 754b4c07 Changes: ```` rustup https://github.com/rust-lang/rust/pull/54071/ dependencies: update pulldown-cmark from 0.1 to 0.2 s/file_map/source_map ````
2018-11-23 12:52:47 +01:00
[[package]]
name = "pulldown-cmark"
version = "0.2.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"bitflags 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)",
"getopts 0.2.17 (registry+https://github.com/rust-lang/crates.io-index)",
]
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
[[package]]
name = "quick-error"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
version = "1.2.2"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
[[package]]
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
name = "quine-mc_cluskey"
version = "0.2.4"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
[[package]]
name = "quote"
version = "0.3.15"
source = "registry+https://github.com/rust-lang/crates.io-index"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
[[package]]
name = "quote"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "0.6.10"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update RLS and Rustfmt
2018-11-19 05:21:10 +01:00
"proc-macro2 0.4.24 (registry+https://github.com/rust-lang/crates.io-index)",
Bump to 1.27.0 Also update some `Cargo.lock` dependencies, finishing up some final steps of our [release process]! This doesn't update the bootstrap compiler just yet but that will come in a follow-up PR. [release process]: https://forge.rust-lang.org/release-process.html
2018-04-02 17:43:55 +02:00
]
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
[[package]]
name = "racer"
Update Clippy, RLS and Rustfmt
2019-03-18 18:34:18 +01:00
version = "2.1.21"
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
dependencies = [
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"bitflags 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"clap 2.32.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS and Rustfmt
2018-11-19 05:21:10 +01:00
"derive_more 0.13.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS
2018-12-10 08:58:08 +01:00
"env_logger 0.6.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"humantime 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS
2018-12-10 08:58:08 +01:00
"lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock
2019-02-18 10:32:58 +01:00
"rls-span 0.4.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update Clippy, RLS and Rustfmt
2019-03-18 18:34:18 +01:00
"rustc-ap-syntax 407.0.0 (registry+https://github.com/rust-lang/crates.io-index)",
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
]
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
Update Cargo submodule Required moving all fulldeps tests depending on `rand` to different locations as now there's multiple `rand` crates that can't be implicitly linked against.
2018-02-26 18:07:16 +01:00
[[package]]
name = "rand"
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
version = "0.4.3"
Update Cargo submodule Required moving all fulldeps tests depending on `rand` to different locations as now there's multiple `rand` crates that can't be implicitly linked against.
2018-02-26 18:07:16 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"fuchsia-zircon 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
]
Update RLS and rustfmt.
2018-07-26 23:58:55 +02:00
[[package]]
name = "rand"
Update submodules to include rust-lang-nursery/rust-clippy#3189 and rust-lang-nursery/rls#1054.
2018-09-15 10:40:25 +02:00
version = "0.5.5"
Update RLS and rustfmt.
2018-07-26 23:58:55 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"cloudabi 0.0.3 (registry+https://github.com/rust-lang/crates.io-index)",
"fuchsia-zircon 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"rand_core 0.2.2 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS and rustfmt.
2018-07-26 23:58:55 +02:00
]
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
[[package]]
name = "rand"
version = "0.6.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"cloudabi 0.0.3 (registry+https://github.com/rust-lang/crates.io-index)",
"fuchsia-zircon 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"rand_chacha 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
"rand_core 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)",
"rand_hc 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
"rand_isaac 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)",
"rand_pcg 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)",
"rand_xorshift 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
"rustc_version 0.2.3 (registry+https://github.com/rust-lang/crates.io-index)",
"winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "rand_chacha"
version = "0.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo.lock
2019-03-26 11:29:21 +01:00
"rand_core 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"rustc_version 0.2.3 (registry+https://github.com/rust-lang/crates.io-index)",
]
Update RLS and rustfmt.
2018-07-26 23:58:55 +02:00
[[package]]
name = "rand_core"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "0.2.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"rand_core 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "rand_core"
version = "0.3.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
[[package]]
name = "rand_hc"
version = "0.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo.lock
2019-03-26 11:29:21 +01:00
"rand_core 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
]
[[package]]
name = "rand_isaac"
version = "0.1.1"
Update RLS and rustfmt.
2018-07-26 23:58:55 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
dependencies = [
"rand_core 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "rand_pcg"
version = "0.1.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"rand_core 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)",
"rustc_version 0.2.3 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "rand_xorshift"
version = "0.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo.lock
2019-03-26 11:29:21 +01:00
"rand_core 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
]
Update RLS and rustfmt.
2018-07-26 23:58:55 +02:00
Update RLS
2018-02-26 04:15:45 +01:00
[[package]]
name = "rayon"
Bump to 1.27.0 Also update some `Cargo.lock` dependencies, finishing up some final steps of our [release process]! This doesn't update the bootstrap compiler just yet but that will come in a follow-up PR. [release process]: https://forge.rust-lang.org/release-process.html
2018-04-02 17:43:55 +02:00
version = "1.0.1"
Update RLS
2018-02-26 04:15:45 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Bump to 1.27.0 Also update some `Cargo.lock` dependencies, finishing up some final steps of our [release process]! This doesn't update the bootstrap compiler just yet but that will come in a follow-up PR. [release process]: https://forge.rust-lang.org/release-process.html
2018-04-02 17:43:55 +02:00
"either 1.5.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS
2018-02-26 04:15:45 +01:00
"rayon-core 1.4.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
]
[[package]]
name = "rayon-core"
Update RLS
2018-02-26 04:15:45 +01:00
version = "1.4.0"
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update RLS
2018-02-26 04:15:45 +01:00
"crossbeam-deque 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS
2018-12-10 08:58:08 +01:00
"lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo and its dependencies This'll probably have a bunch of build errors, so let's try and head those off and find them sooner rather than later!
2018-01-08 22:56:22 +01:00
"num_cpus 1.8.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"rand 0.4.3 (registry+https://github.com/rust-lang/crates.io-index)",
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
]
Update RLS and Rustfmt
2017-09-22 03:58:35 +02:00
[[package]]
name = "redox_syscall"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "0.1.43"
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
[[package]]
name = "redox_termios"
version = "0.1.1"
Update RLS and Rustfmt
2017-09-22 03:58:35 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"redox_syscall 0.1.43 (registry+https://github.com/rust-lang/crates.io-index)",
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
]
Update RLS and Rustfmt
2017-09-22 03:58:35 +02:00
Update Cargo.lock
2019-02-18 10:32:58 +01:00
[[package]]
name = "redox_users"
version = "0.2.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"argon2rs 0.2.5 (registry+https://github.com/rust-lang/crates.io-index)",
"failure 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)",
"rand 0.4.3 (registry+https://github.com/rust-lang/crates.io-index)",
"redox_syscall 0.1.43 (registry+https://github.com/rust-lang/crates.io-index)",
]
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
[[package]]
name = "regex"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
version = "0.2.11"
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"aho-corasick 0.6.9 (registry+https://github.com/rust-lang/crates.io-index)",
"memchr 2.1.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"regex-syntax 0.5.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"thread_local 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"utf8-ranges 1.0.2 (registry+https://github.com/rust-lang/crates.io-index)",
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
]
Update the clippy and miri submodules
2018-05-11 14:11:06 +02:00
[[package]]
name = "regex"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "1.1.0"
Update the clippy and miri submodules
2018-05-11 14:11:06 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"aho-corasick 0.6.9 (registry+https://github.com/rust-lang/crates.io-index)",
"memchr 2.1.1 (registry+https://github.com/rust-lang/crates.io-index)",
"regex-syntax 0.6.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"thread_local 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"utf8-ranges 1.0.2 (registry+https://github.com/rust-lang/crates.io-index)",
Update the clippy and miri submodules
2018-05-11 14:11:06 +02:00
]
Update Cargo submodule Required moving all fulldeps tests depending on `rand` to different locations as now there's multiple `rand` crates that can't be implicitly linked against.
2018-02-26 18:07:16 +01:00
[[package]]
name = "regex-syntax"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
version = "0.5.6"
Update Cargo submodule Required moving all fulldeps tests depending on `rand` to different locations as now there's multiple `rand` crates that can't be implicitly linked against.
2018-02-26 18:07:16 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"ucd-util 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Required moving all fulldeps tests depending on `rand` to different locations as now there's multiple `rand` crates that can't be implicitly linked against.
2018-02-26 18:07:16 +01:00
]
Update the clippy and miri submodules
2018-05-11 14:11:06 +02:00
[[package]]
name = "regex-syntax"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "0.6.4"
Update the clippy and miri submodules
2018-05-11 14:11:06 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"ucd-util 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)",
Update the clippy and miri submodules
2018-05-11 14:11:06 +02:00
]
travis: Parallelize tests on Android Currently our slowest test suite on android, run-pass, takes over 5 times longer than the x86_64 component (~400 -> ~2200s). Typically QEMU emulation does indeed add overhead, but not 5x for this kind of workload. One of the slowest parts of the Android process is that *compilation* happens serially. Tests themselves need to run single-threaded on the emulator (due to how the test harness works) and this forces the compiles themselves to be single threaded. Now Travis gives us more than one core per machine, so it'd be much better if we could take advantage of them! The emulator itself is still fundamentally single-threaded, but we should see a nice speedup by sending binaries for it to run much more quickly. It turns out that we've already got all the tools to do this in-tree. The qemu-test-{server,client} that are in use for the ARM Linux testing are a perfect match for the Android emulator. This commit migrates the custom adb management code in compiletest/rustbuild to the same qemu-test-{server,client} implementation that ARM Linux uses. This allows us to lift the parallelism restriction on the compiletest test suites, namely run-pass. Consequently although we'll still basically run the tests themselves in single threaded mode we'll be able to compile all of them in parallel, keeping the pipeline much more full and using more cores for the work at hand. Additionally the architecture here should be a bit speedier as it should have less overhead than adb which is a whole new process on both the host and the emulator! Locally on an 8 core machine I've seen the run-pass test suite speed up from taking nearly an hour to only taking 6 minutes. I don't think we'll see quite a drastic speedup on Travis but I'm hoping this change can place the Android tests well below 2 hours instead of just above 2 hours. Because the client/server here are now repurposed for more than just QEMU, they've been renamed to `remote-test-{server,client}`. Note that this PR does not currently modify how debuginfo tests are executed on Android. While parallelizable it wouldn't be quite as easy, so that's left to another day. Thankfully that test suite is much smaller than the run-pass test suite. As a final fix I discovered that the ARM and Android test suites were actually running all library unit tests (e.g. stdtest, coretest, etc) twice. I've corrected that to only run tests once which should also give a nice boost in overall cycle time here.
2017-04-26 17:52:19 +02:00
[[package]]
name = "remote-test-client"
version = "0.1.0"
[[package]]
name = "remote-test-server"
version = "0.1.0"
Update Cargo submodule Required moving all fulldeps tests depending on `rand` to different locations as now there's multiple `rand` crates that can't be implicitly linked against.
2018-02-26 18:07:16 +01:00
[[package]]
name = "remove_dir_all"
Update the Cargo submodule
2018-04-18 17:43:59 +02:00
version = "0.5.1"
Update Cargo submodule Required moving all fulldeps tests depending on `rand` to different locations as now there's multiple `rand` crates that can't be implicitly linked against.
2018-02-26 18:07:16 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Required moving all fulldeps tests depending on `rand` to different locations as now there's multiple `rand` crates that can't be implicitly linked against.
2018-02-26 18:07:16 +01:00
]
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
[[package]]
name = "rls"
Update Clippy, RLS and Rustfmt
2019-03-18 18:34:18 +01:00
version = "1.35.0"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
dependencies = [
Update cargo, rls
2019-03-04 22:18:44 +01:00
"cargo 0.36.0",
submodule: update rls from c9d25b667a to f331ff7
2019-02-03 01:48:18 +01:00
"cargo_metadata 0.7.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update clippy and rls
2018-07-15 00:01:24 +02:00
"clippy_lints 0.0.212",
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
"crossbeam-channel 0.3.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock
2019-01-10 13:42:14 +01:00
"difference 2.0.0 (registry+https://github.com/rust-lang/crates.io-index)",
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
"env_logger 0.6.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo
2019-02-03 23:42:29 +01:00
"failure 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)",
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
"futures 0.1.21 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock
2019-02-18 10:32:58 +01:00
"heck 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock
2019-01-10 13:42:14 +01:00
"home 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)",
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
"itertools 0.8.0 (registry+https://github.com/rust-lang/crates.io-index)",
submodule: update rls from c9d25b667a to f331ff7
2019-02-03 01:48:18 +01:00
"jsonrpc-core 10.0.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS
2018-12-10 08:58:08 +01:00
"lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo, rls
2019-03-04 22:18:44 +01:00
"lsp-codec 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock
2019-02-18 10:32:58 +01:00
"lsp-types 0.55.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS
2018-02-14 09:09:51 +01:00
"num_cpus 1.8.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS, Rustfmt, Cargo, and Clippy
2018-07-06 02:34:00 +02:00
"ordslice 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Clippy, RLS and Rustfmt
2019-03-18 18:34:18 +01:00
"racer 2.1.21 (registry+https://github.com/rust-lang/crates.io-index)",
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
"rand 0.6.1 (registry+https://github.com/rust-lang/crates.io-index)",
Bump to 1.27.0 Also update some `Cargo.lock` dependencies, finishing up some final steps of our [release process]! This doesn't update the bootstrap compiler just yet but that will come in a follow-up PR. [release process]: https://forge.rust-lang.org/release-process.html
2018-04-02 17:43:55 +02:00
"rayon 1.0.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"regex 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock
2019-02-18 10:32:58 +01:00
"rls-analysis 0.16.12 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS and Rustfmt
2018-11-19 05:21:10 +01:00
"rls-blacklist 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock
2019-02-18 10:32:58 +01:00
"rls-data 0.18.2 (registry+https://github.com/rust-lang/crates.io-index)",
Bump Clippy and RLS
2019-03-10 17:03:32 +01:00
"rls-rustc 0.6.0",
Update Cargo.lock
2019-02-18 10:32:58 +01:00
"rls-span 0.4.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS and Rustfmt
2018-11-19 05:21:10 +01:00
"rls-vfs 0.7.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Rustfmt to 0.99.4 This pulls the same version of rustc-ap-* libs as RLS does.
2018-08-31 21:52:25 +02:00
"rustc-serialize 0.3.24 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Bring in some fixes for `cargo fix` notably
2018-07-31 23:16:55 +02:00
"rustc-workspace-hack 1.0.0",
Update Cargo.lock
2019-01-10 13:42:14 +01:00
"rustc_tools_util 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update rustfmt to 1.2.0
2019-03-27 02:37:01 +01:00
"rustfmt-nightly 1.2.0",
Update cargo, rls, miri
2018-12-17 19:23:04 +01:00
"serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"serde_derive 1.0.81 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock
2019-02-18 10:32:58 +01:00
"serde_ignored 0.0.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"serde_json 1.0.33 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock
2019-01-10 13:42:14 +01:00
"tempfile 3.0.5 (registry+https://github.com/rust-lang/crates.io-index)",
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
"tokio 0.1.14 (registry+https://github.com/rust-lang/crates.io-index)",
"tokio-process 0.2.3 (registry+https://github.com/rust-lang/crates.io-index)",
"tokio-timer 0.2.8 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"toml 0.4.10 (registry+https://github.com/rust-lang/crates.io-index)",
"url 1.7.2 (registry+https://github.com/rust-lang/crates.io-index)",
"walkdir 2.2.7 (registry+https://github.com/rust-lang/crates.io-index)",
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
]
[[package]]
name = "rls-analysis"
Update Cargo.lock
2019-02-18 10:32:58 +01:00
version = "0.16.12"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Reduce the numbers of syn versions compiled from 4 to 2 The last remaining one comes from mdbook. Unfortunately updating it breaks everything
2018-12-08 15:11:47 +01:00
"derive-new 0.5.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS, Rustfmt, Cargo, and Clippy
2018-07-06 02:34:00 +02:00
"fst 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)",
"itertools 0.7.8 (registry+https://github.com/rust-lang/crates.io-index)",
Bump serde_json 1.0.24 -> 1.0.25 This fixes 'cannot find macro `json_internal!` in this scope' RLS compilation error in Rust CI, presumably due to a local macro fix in serde_json 1.0.25 (https://github.com/serde-rs/json/commit/e40cbad70b39a0dd7975be8e5ad9018e2d45f791)
2018-08-25 18:17:55 +02:00
"json 0.11.13 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock
2019-02-18 10:32:58 +01:00
"rls-data 0.18.2 (registry+https://github.com/rust-lang/crates.io-index)",
"rls-span 0.4.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo Brings in some perf improvements!
2017-06-05 18:36:48 +02:00
"rustc-serialize 0.3.24 (registry+https://github.com/rust-lang/crates.io-index)",
]
Update rls-data dep
2017-08-02 06:57:50 +02:00
[[package]]
Update RLS
2018-02-14 09:09:51 +01:00
name = "rls-blacklist"
Update RLS and Rustfmt
2018-11-19 05:21:10 +01:00
version = "0.1.3"
Update rls-data dep
2017-08-02 06:57:50 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Emit data::Impl in save-analysis
2018-02-02 08:29:59 +01:00
[[package]]
name = "rls-data"
Update Cargo.lock
2019-02-18 10:32:58 +01:00
version = "0.18.2"
Emit data::Impl in save-analysis
2018-02-02 08:29:59 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo.lock
2019-02-18 10:32:58 +01:00
"rls-span 0.4.1 (registry+https://github.com/rust-lang/crates.io-index)",
Emit data::Impl in save-analysis
2018-02-02 08:29:59 +01:00
"rustc-serialize 0.3.24 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo, rls, miri
2018-12-17 19:23:04 +01:00
"serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"serde_derive 1.0.81 (registry+https://github.com/rust-lang/crates.io-index)",
Emit data::Impl in save-analysis
2018-02-02 08:29:59 +01:00
]
Update rls
2017-08-30 07:09:36 +02:00
[[package]]
name = "rls-rustc"
Bump Clippy and RLS
2019-03-10 17:03:32 +01:00
version = "0.6.0"
Update rls
2017-08-30 07:09:36 +02:00
save-analysis: depend on the rls-data crate
2017-03-14 03:16:44 +01:00
[[package]]
name = "rls-span"
Update Cargo.lock
2019-02-18 10:32:58 +01:00
version = "0.4.1"
Move to using 0.1 versions of crates, rather than GH links Also adds a fixme and does cargo update
2017-03-15 09:20:23 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
save-analysis: depend on the rls-data crate
2017-03-14 03:16:44 +01:00
dependencies = [
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
"rustc-serialize 0.3.24 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo, rls, miri
2018-12-17 19:23:04 +01:00
"serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"serde_derive 1.0.81 (registry+https://github.com/rust-lang/crates.io-index)",
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
]
[[package]]
name = "rls-vfs"
Update RLS and Rustfmt
2018-11-19 05:21:10 +01:00
version = "0.7.0"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock
2019-02-18 10:32:58 +01:00
"rls-span 0.4.1 (registry+https://github.com/rust-lang/crates.io-index)",
save-analysis: depend on the rls-data crate
2017-03-14 03:16:44 +01:00
]
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
[[package]]
name = "rustbook"
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
version = "0.1.0"
dependencies = [
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"clap 2.32.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update MDBook
2018-04-21 23:06:13 +02:00
"mdbook 0.1.7 (registry+https://github.com/rust-lang/crates.io-index)",
Update to newer version of mdbook(2)
2019-01-19 03:39:37 +01:00
"mdbook 0.2.3 (registry+https://github.com/rust-lang/crates.io-index)",
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
]
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
[[package]]
name = "rustc"
version = "0.0.0"
dependencies = [
"arena 0.0.0",
bump backtrace version to get prettier pretty-printing
2018-12-11 22:36:24 +01:00
"backtrace 0.3.11 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"bitflags 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"byteorder 1.2.7 (registry+https://github.com/rust-lang/crates.io-index)",
Handle sub-typing in chalk-engine
2018-11-28 22:11:00 +01:00
"chalk-engine 0.9.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"flate2 1.0.6 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"fmt_macros 0.0.0",
"graphviz 0.0.0",
Update cargo
2019-03-29 04:13:13 +01:00
"jobserver 0.1.13 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS
2018-12-10 08:58:08 +01:00
"lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Use multiple threads by default. Limits tests to one thread. Do some renaming.
2019-01-28 15:51:47 +01:00
"num_cpus 1.8.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update parking_lot to 0.7 Unfortunately this'll dupe parking_lot until the data_structures crate is published and be updated in rls in conjunction with crossbeam-channel
2019-02-22 13:49:19 +01:00
"parking_lot 0.7.1 (registry+https://github.com/rust-lang/crates.io-index)",
adopt polonius-engine 0.6.2 Also datafrog 2.0.1, which works around a rustdoc bug
2019-01-02 20:45:22 +01:00
"polonius-engine 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock
2019-02-27 15:17:12 +01:00
"rustc-rayon 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)",
"rustc-rayon-core 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)",
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
"rustc_apfloat 0.0.0",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"rustc_data_structures 0.0.0",
"rustc_errors 0.0.0",
Move rustc::util::fs into separate (new) crate
2018-08-03 23:31:03 +02:00
"rustc_fs_util 0.0.0",
Update Cargo.lock
2019-03-01 01:22:10 +01:00
"rustc_macros 0.1.0",
Rename rustc_back::target to rustc_target::spec.
2017-12-08 20:18:21 +01:00
"rustc_target 0.0.0",
update Cargo.lock
2019-02-26 11:15:52 +01:00
"scoped-tls 1.0.0 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"serialize 0.0.0",
Upgrade `smallvec` to 0.6.7 and use the new `may_dangle` feature.
2018-11-28 22:52:22 +01:00
"smallvec 0.6.7 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"syntax 0.0.0",
"syntax_pos 0.0.0",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"tempfile 3.0.5 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
]
Update RLS, Rustfmt, and Cargo
2018-05-28 00:16:42 +02:00
[[package]]
name = "rustc-ap-arena"
Update Clippy, RLS and Rustfmt
2019-03-18 18:34:18 +01:00
version = "407.0.0"
Update rustfmt to 0.3.6
2018-01-18 15:40:37 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Clippy, RLS and Rustfmt
2019-03-18 18:34:18 +01:00
"rustc-ap-rustc_data_structures 407.0.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update rustfmt to 0.3.6
2018-01-18 15:40:37 +01:00
]
Update RLS and Rustfmt
2018-11-19 05:21:10 +01:00
[[package]]
name = "rustc-ap-graphviz"
Update Clippy, RLS and Rustfmt
2019-03-18 18:34:18 +01:00
version = "407.0.0"
Update RLS and Rustfmt
2018-11-19 05:21:10 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Update Cargo submodule Bring in some fixes for `cargo fix` notably
2018-07-31 23:16:55 +02:00
[[package]]
name = "rustc-ap-rustc_cratesio_shim"
Update Clippy, RLS and Rustfmt
2019-03-18 18:34:18 +01:00
version = "407.0.0"
Update Cargo submodule Bring in some fixes for `cargo fix` notably
2018-07-31 23:16:55 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"bitflags 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update rustfmt and RLS
2018-09-25 04:40:42 +02:00
"unicode-width 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Bring in some fixes for `cargo fix` notably
2018-07-31 23:16:55 +02:00
]
Update rustfmt to 0.3.6
2018-01-18 15:40:37 +01:00
[[package]]
name = "rustc-ap-rustc_data_structures"
Update Clippy, RLS and Rustfmt
2019-03-18 18:34:18 +01:00
version = "407.0.0"
Update rustfmt to 0.3.6
2018-01-18 15:40:37 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"cfg-if 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS
2018-12-10 08:58:08 +01:00
"ena 0.11.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo
2019-03-29 04:13:13 +01:00
"jobserver 0.1.13 (registry+https://github.com/rust-lang/crates.io-index)",
Update Clippy, RLS and Rustfmt
2019-03-18 18:34:18 +01:00
"lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Clippy, RLS and Rustfmt
2019-03-18 18:34:18 +01:00
"parking_lot 0.7.1 (registry+https://github.com/rust-lang/crates.io-index)",
"rustc-ap-graphviz 407.0.0 (registry+https://github.com/rust-lang/crates.io-index)",
"rustc-ap-rustc_cratesio_shim 407.0.0 (registry+https://github.com/rust-lang/crates.io-index)",
"rustc-ap-serialize 407.0.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Bring in some fixes for `cargo fix` notably
2018-07-31 23:16:55 +02:00
"rustc-hash 1.0.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock
2019-02-27 15:17:12 +01:00
"rustc-rayon 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)",
"rustc-rayon-core 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)",
Upgrade `smallvec` to 0.6.7 and use the new `may_dangle` feature.
2018-11-28 22:52:22 +01:00
"smallvec 0.6.7 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Bring in some fixes for `cargo fix` notably
2018-07-31 23:16:55 +02:00
"stable_deref_trait 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
]
Update rustfmt to 0.3.6
2018-01-18 15:40:37 +01:00
[[package]]
name = "rustc-ap-rustc_errors"
Update Clippy, RLS and Rustfmt
2019-03-18 18:34:18 +01:00
version = "407.0.0"
Update rustfmt to 0.3.6
2018-01-18 15:40:37 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
revert accidental atty downgrade
2018-07-27 15:10:52 +02:00
"atty 0.2.11 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Clippy, RLS and Rustfmt
2019-03-18 18:34:18 +01:00
"rustc-ap-rustc_cratesio_shim 407.0.0 (registry+https://github.com/rust-lang/crates.io-index)",
"rustc-ap-rustc_data_structures 407.0.0 (registry+https://github.com/rust-lang/crates.io-index)",
"rustc-ap-serialize 407.0.0 (registry+https://github.com/rust-lang/crates.io-index)",
"rustc-ap-syntax_pos 407.0.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"termcolor 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Bring in some fixes for `cargo fix` notably
2018-07-31 23:16:55 +02:00
"unicode-width 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)",
]
Update RLS and Rustfmt
2018-05-01 21:50:58 +02:00
[[package]]
name = "rustc-ap-rustc_target"
Update Clippy, RLS and Rustfmt
2019-03-18 18:34:18 +01:00
version = "407.0.0"
Update RLS and Rustfmt
2018-05-01 21:50:58 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"bitflags 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Clippy, RLS and Rustfmt
2019-03-18 18:34:18 +01:00
"rustc-ap-rustc_cratesio_shim 407.0.0 (registry+https://github.com/rust-lang/crates.io-index)",
"rustc-ap-rustc_data_structures 407.0.0 (registry+https://github.com/rust-lang/crates.io-index)",
"rustc-ap-serialize 407.0.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS and Rustfmt
2018-05-01 21:50:58 +02:00
]
Update Cargo submodule Bring in some fixes for `cargo fix` notably
2018-07-31 23:16:55 +02:00
[[package]]
name = "rustc-ap-serialize"
Update Clippy, RLS and Rustfmt
2019-03-18 18:34:18 +01:00
version = "407.0.0"
Update RLS and Rustfmt
2018-06-07 05:14:49 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Update Rustfmt to 0.99.4 This pulls the same version of rustc-ap-* libs as RLS does.
2018-08-31 21:52:25 +02:00
dependencies = [
Upgrade `smallvec` to 0.6.7 and use the new `may_dangle` feature.
2018-11-28 22:52:22 +01:00
"smallvec 0.6.7 (registry+https://github.com/rust-lang/crates.io-index)",
Update Rustfmt to 0.99.4 This pulls the same version of rustc-ap-* libs as RLS does.
2018-08-31 21:52:25 +02:00
]
Update RLS and Rustfmt
2018-06-07 05:14:49 +02:00
Update Cargo submodule Bring in some fixes for `cargo fix` notably
2018-07-31 23:16:55 +02:00
[[package]]
name = "rustc-ap-syntax"
Update Clippy, RLS and Rustfmt
2019-03-18 18:34:18 +01:00
version = "407.0.0"
Update Cargo submodule Bring in some fixes for `cargo fix` notably
2018-07-31 23:16:55 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"bitflags 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Clippy, RLS and Rustfmt
2019-03-18 18:34:18 +01:00
"rustc-ap-rustc_data_structures 407.0.0 (registry+https://github.com/rust-lang/crates.io-index)",
"rustc-ap-rustc_errors 407.0.0 (registry+https://github.com/rust-lang/crates.io-index)",
"rustc-ap-rustc_target 407.0.0 (registry+https://github.com/rust-lang/crates.io-index)",
"rustc-ap-serialize 407.0.0 (registry+https://github.com/rust-lang/crates.io-index)",
"rustc-ap-syntax_pos 407.0.0 (registry+https://github.com/rust-lang/crates.io-index)",
"scoped-tls 1.0.0 (registry+https://github.com/rust-lang/crates.io-index)",
Upgrade `smallvec` to 0.6.7 and use the new `may_dangle` feature.
2018-11-28 22:52:22 +01:00
"smallvec 0.6.7 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Bring in some fixes for `cargo fix` notably
2018-07-31 23:16:55 +02:00
]
Update RLS and Rustfmt
2018-06-07 05:14:49 +02:00
[[package]]
name = "rustc-ap-syntax_pos"
Update Clippy, RLS and Rustfmt
2019-03-18 18:34:18 +01:00
version = "407.0.0"
Update Cargo submodule Bring in some fixes for `cargo fix` notably
2018-07-31 23:16:55 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"cfg-if 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Clippy, RLS and Rustfmt
2019-03-18 18:34:18 +01:00
"rustc-ap-arena 407.0.0 (registry+https://github.com/rust-lang/crates.io-index)",
"rustc-ap-rustc_data_structures 407.0.0 (registry+https://github.com/rust-lang/crates.io-index)",
"rustc-ap-serialize 407.0.0 (registry+https://github.com/rust-lang/crates.io-index)",
"scoped-tls 1.0.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Bring in some fixes for `cargo fix` notably
2018-07-31 23:16:55 +02:00
"unicode-width 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)",
]
Update to the oxidized rust-installer
2017-05-09 00:01:13 +02:00
[[package]]
name = "rustc-demangle"
std: Use `rustc_demangle` from crates.io No more need to duplicate the demangling routine between crates.io and the standard library, we can use the exact same one!
2018-12-14 23:37:51 +01:00
version = "0.1.10"
Update to the oxidized rust-installer
2017-05-09 00:01:13 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
std: Use `rustc_demangle` from crates.io No more need to duplicate the demangling routine between crates.io and the standard library, we can use the exact same one!
2018-12-14 23:37:51 +01:00
dependencies = [
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"compiler_builtins 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)",
std: Use `rustc_demangle` from crates.io No more need to duplicate the demangling routine between crates.io and the standard library, we can use the exact same one!
2018-12-14 23:37:51 +01:00
"rustc-std-workspace-core 1.0.0",
]
Update to the oxidized rust-installer
2017-05-09 00:01:13 +02:00
get `rustc_hash` from external crate
2018-05-24 14:48:02 +02:00
[[package]]
name = "rustc-hash"
Update rustc-hash to hash up to 8 bytes at once with FxHasher
2018-05-24 05:37:40 +02:00
version = "1.0.1"
get `rustc_hash` from external crate
2018-05-24 14:48:02 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Update rustc-hash to hash up to 8 bytes at once with FxHasher
2018-05-24 05:37:40 +02:00
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"byteorder 1.2.7 (registry+https://github.com/rust-lang/crates.io-index)",
Update rustc-hash to hash up to 8 bytes at once with FxHasher
2018-05-24 05:37:40 +02:00
]
get `rustc_hash` from external crate
2018-05-24 14:48:02 +02:00
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
[[package]]
name = "rustc-main"
version = "0.0.0"
dependencies = [
Update Cargo.lock
2019-03-26 11:29:21 +01:00
"jemalloc-sys 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)",
Move fake rustc_codegen_ssa dependency from rustc_driver to rustc-main
2018-11-19 18:28:44 +01:00
"rustc_codegen_ssa 0.0.0",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"rustc_driver 0.0.0",
Rename rustc_back::target to rustc_target::spec.
2017-12-08 20:18:21 +01:00
"rustc_target 0.0.0",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
]
Update Cargo.lock
2018-05-12 04:11:03 +02:00
[[package]]
name = "rustc-rayon"
Update Cargo.lock
2019-02-27 15:17:12 +01:00
version = "0.1.2"
Update Cargo.lock
2018-05-12 04:11:03 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo.lock
2019-02-27 15:17:12 +01:00
"crossbeam-deque 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock
2018-05-12 04:11:03 +02:00
"either 1.5.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock
2019-02-27 15:17:12 +01:00
"rustc-rayon-core 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock
2018-05-12 04:11:03 +02:00
]
[[package]]
name = "rustc-rayon-core"
Update Cargo.lock
2019-02-27 15:17:12 +01:00
version = "0.1.2"
Update Cargo.lock
2018-05-12 04:11:03 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"crossbeam-deque 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS
2018-12-10 08:58:08 +01:00
"lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock
2018-05-12 04:11:03 +02:00
"num_cpus 1.8.0 (registry+https://github.com/rust-lang/crates.io-index)",
]
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
[[package]]
name = "rustc-serialize"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
version = "0.3.24"
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
std: Depend directly on crates.io crates 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-11-20 06:52:50 +01:00
[[package]]
name = "rustc-std-workspace-core"
version = "1.0.0"
dependencies = [
"core 0.0.0",
]
Update Cargo submodule Bring in some fixes for `cargo fix` notably
2018-07-31 23:16:55 +02:00
[[package]]
name = "rustc-workspace-hack"
version = "1.0.0"
dependencies = [
Adjust cargo workspace hack to miri/cargo interactions
2019-01-01 14:36:05 +01:00
"byteorder 1.2.7 (registry+https://github.com/rust-lang/crates.io-index)",
Update parking_lot to 0.7 Unfortunately this'll dupe parking_lot until the data_structures crate is published and be updated in rls in conjunction with crossbeam-channel
2019-02-22 13:49:19 +01:00
"parking_lot 0.7.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock
2018-10-04 12:51:58 +02:00
"rand 0.5.5 (registry+https://github.com/rust-lang/crates.io-index)",
Adjust cargo workspace hack to miri/cargo interactions
2019-01-01 14:36:05 +01:00
"scopeguard 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo, rls, miri
2018-12-17 19:23:04 +01:00
"serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"serde_json 1.0.33 (registry+https://github.com/rust-lang/crates.io-index)",
"smallvec 0.6.7 (registry+https://github.com/rust-lang/crates.io-index)",
"syn 0.15.22 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Bring in some fixes for `cargo fix` notably
2018-07-31 23:16:55 +02:00
]
rustc: Implement the #[global_allocator] attribute This PR is an implementation of [RFC 1974] which specifies a new method of defining a global allocator for a program. This obsoletes the old `#![allocator]` attribute and also removes support for it. [RFC 1974]: https://github.com/rust-lang/rfcs/pull/197 The new `#[global_allocator]` attribute solves many issues encountered with the `#![allocator]` attribute such as composition and restrictions on the crate graph itself. The compiler now has much more control over the ABI of the allocator and how it's implemented, allowing much more freedom in terms of how this feature is implemented. cc #27389
2017-06-03 23:54:08 +02:00
[[package]]
name = "rustc_allocator"
version = "0.0.0"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
rustc: Implement the #[global_allocator] attribute This PR is an implementation of [RFC 1974] which specifies a new method of defining a global allocator for a program. This obsoletes the old `#![allocator]` attribute and also removes support for it. [RFC 1974]: https://github.com/rust-lang/rfcs/pull/197 The new `#[global_allocator]` attribute solves many issues encountered with the `#![allocator]` attribute such as composition and restrictions on the crate graph itself. The compiler now has much more control over the ABI of the allocator and how it's implemented, allowing much more freedom in terms of how this feature is implemented. cc #27389
2017-06-03 23:54:08 +02:00
"rustc 0.0.0",
Move SmallVec and ThinVec out of libsyntax
2018-08-05 12:04:56 +02:00
"rustc_data_structures 0.0.0",
rustc: Implement the #[global_allocator] attribute This PR is an implementation of [RFC 1974] which specifies a new method of defining a global allocator for a program. This obsoletes the old `#![allocator]` attribute and also removes support for it. [RFC 1974]: https://github.com/rust-lang/rfcs/pull/197 The new `#[global_allocator]` attribute solves many issues encountered with the `#![allocator]` attribute such as composition and restrictions on the crate graph itself. The compiler now has much more control over the ABI of the allocator and how it's implemented, allowing much more freedom in terms of how this feature is implemented. cc #27389
2017-06-03 23:54:08 +02:00
"rustc_errors 0.0.0",
rustc_target: move in syntax::abi and flip dependency.
2018-04-25 18:30:39 +02:00
"rustc_target 0.0.0",
Upgrade `smallvec` to 0.6.7 and use the new `may_dangle` feature.
2018-11-28 22:52:22 +01:00
"smallvec 0.6.7 (registry+https://github.com/rust-lang/crates.io-index)",
rustc: Implement the #[global_allocator] attribute This PR is an implementation of [RFC 1974] which specifies a new method of defining a global allocator for a program. This obsoletes the old `#![allocator]` attribute and also removes support for it. [RFC 1974]: https://github.com/rust-lang/rfcs/pull/197 The new `#[global_allocator]` attribute solves many issues encountered with the `#![allocator]` attribute such as composition and restrictions on the crate graph itself. The compiler now has much more control over the ABI of the allocator and how it's implemented, allowing much more freedom in terms of how this feature is implemented. cc #27389
2017-06-03 23:54:08 +02:00
"syntax 0.0.0",
"syntax_pos 0.0.0",
]
rustc_apfloat: introduce the base Float API.
2017-07-08 19:46:43 +02:00
[[package]]
name = "rustc_apfloat"
version = "0.0.0"
dependencies = [
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"bitflags 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)",
Remove rustc_bitflags; use the bitflags crate
2017-09-08 21:08:01 +02:00
"rustc_cratesio_shim 0.0.0",
Upgrade `smallvec` to 0.6.7 and use the new `may_dangle` feature.
2018-11-28 22:52:22 +01:00
"smallvec 0.6.7 (registry+https://github.com/rust-lang/crates.io-index)",
rustc_apfloat: introduce the base Float API.
2017-07-08 19:46:43 +02:00
]
sanitizer support
2016-12-30 05:28:11 +01:00
[[package]]
name = "rustc_asan"
version = "0.0.0"
dependencies = [
rustc: Implement the #[global_allocator] attribute This PR is an implementation of [RFC 1974] which specifies a new method of defining a global allocator for a program. This obsoletes the old `#![allocator]` attribute and also removes support for it. [RFC 1974]: https://github.com/rust-lang/rfcs/pull/197 The new `#[global_allocator]` attribute solves many issues encountered with the `#![allocator]` attribute such as composition and restrictions on the crate graph itself. The compiler now has much more control over the ABI of the allocator and how it's implemented, allowing much more freedom in terms of how this feature is implemented. cc #27389
2017-06-03 23:54:08 +02:00
"alloc 0.0.0",
use helper function in the rebuild logic of the rustc_*san crates
2017-02-05 02:10:29 +01:00
"build_helper 0.1.0",
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"cmake 0.1.33 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"compiler_builtins 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)",
sanitizer support
2016-12-30 05:28:11 +01:00
"core 0.0.0",
]
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
[[package]]
name = "rustc_borrowck"
version = "0.0.0"
dependencies = [
"graphviz 0.0.0",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"rustc 0.0.0",
Replace Rc with Lrc for shared data
2018-02-27 17:11:14 +01:00
"rustc_data_structures 0.0.0",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"rustc_errors 0.0.0",
"rustc_mir 0.0.0",
"syntax 0.0.0",
"syntax_pos 0.0.0",
]
Rename trans to codegen everywhere.
2018-05-08 15:10:16 +02:00
[[package]]
name = "rustc_codegen_llvm"
version = "0.0.0"
dependencies = [
Update cc crate to include Armv8-M changes
2019-01-09 15:51:22 +01:00
"cc 1.0.28 (registry+https://github.com/rust-lang/crates.io-index)",
Always add all modules to the global ThinLTO module analysis when compiling incrementally.
2018-08-31 15:18:08 +02:00
"memmap 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)",
Rename trans to codegen everywhere.
2018-05-08 15:10:16 +02:00
"num_cpus 1.8.0 (registry+https://github.com/rust-lang/crates.io-index)",
std: Use `rustc_demangle` from crates.io No more need to duplicate the demangling routine between crates.io and the standard library, we can use the exact same one!
2018-12-14 23:37:51 +01:00
"rustc-demangle 0.1.10 (registry+https://github.com/rust-lang/crates.io-index)",
Rename trans to codegen everywhere.
2018-05-08 15:10:16 +02:00
"rustc_llvm 0.0.0",
]
Beginning of moving all backend-agnostic code to rustc_codegen_ssa
2018-10-01 18:07:04 +02:00
[[package]]
name = "rustc_codegen_ssa"
version = "0.0.0"
Separating the back folder between backend-agnostic and LLVM-specific code
2018-10-23 17:01:35 +02:00
dependencies = [
Add rustc_codegen_ssa to sysroot
2018-11-18 18:06:31 +01:00
"bitflags 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update cc crate to include Armv8-M changes
2019-01-09 15:51:22 +01:00
"cc 1.0.28 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo
2019-03-29 04:13:13 +01:00
"jobserver 0.1.13 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Separating the back folder between backend-agnostic and LLVM-specific code
2018-10-23 17:01:35 +02:00
"memmap 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)",
"num_cpus 1.8.0 (registry+https://github.com/rust-lang/crates.io-index)",
Wrap the self-profiler in an `Arc<Mutex<>>` This will allow us to send it across threads and measure things like LLVM time.
2019-02-10 23:23:00 +01:00
"parking_lot 0.7.1 (registry+https://github.com/rust-lang/crates.io-index)",
Add rustc_codegen_ssa to sysroot
2018-11-18 18:06:31 +01:00
"rustc 0.0.0",
std: Use `rustc_demangle` from crates.io No more need to duplicate the demangling routine between crates.io and the standard library, we can use the exact same one!
2018-12-14 23:37:51 +01:00
"rustc-demangle 0.1.10 (registry+https://github.com/rust-lang/crates.io-index)",
Add rustc_codegen_ssa to sysroot
2018-11-18 18:06:31 +01:00
"rustc_allocator 0.0.0",
"rustc_apfloat 0.0.0",
"rustc_codegen_utils 0.0.0",
"rustc_data_structures 0.0.0",
"rustc_errors 0.0.0",
"rustc_fs_util 0.0.0",
"rustc_incremental 0.0.0",
"rustc_mir 0.0.0",
"rustc_target 0.0.0",
"serialize 0.0.0",
"syntax 0.0.0",
"syntax_pos 0.0.0",
Separating the back folder between backend-agnostic and LLVM-specific code
2018-10-23 17:01:35 +02:00
]
Beginning of moving all backend-agnostic code to rustc_codegen_ssa
2018-10-01 18:07:04 +02:00
Rename trans to codegen everywhere.
2018-05-08 15:10:16 +02:00
[[package]]
name = "rustc_codegen_utils"
version = "0.0.0"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"flate2 1.0.6 (registry+https://github.com/rust-lang/crates.io-index)",
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Rename trans to codegen everywhere.
2018-05-08 15:10:16 +02:00
"rustc 0.0.0",
"rustc_data_structures 0.0.0",
Remove rustc_metadata_utils, which contains only one function
2018-10-25 15:11:59 +02:00
"rustc_metadata 0.0.0",
Rename trans to codegen everywhere.
2018-05-08 15:10:16 +02:00
"rustc_mir 0.0.0",
"rustc_target 0.0.0",
"syntax 0.0.0",
"syntax_pos 0.0.0",
]
Remove rustc_bitflags; use the bitflags crate
2017-09-08 21:08:01 +02:00
[[package]]
name = "rustc_cratesio_shim"
version = "0.0.0"
dependencies = [
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"bitflags 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Breaking change upgrades
2018-08-05 00:24:39 +02:00
"unicode-width 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)",
Remove rustc_bitflags; use the bitflags crate
2017-09-08 21:08:01 +02:00
]
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
[[package]]
name = "rustc_data_structures"
version = "0.0.0"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"cfg-if 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update ena to version 0.13.0
2019-03-25 16:45:44 +01:00
"ena 0.13.0 (registry+https://github.com/rust-lang/crates.io-index)",
Added graphviz visualization for obligation forests. This can be a big help when debugging the trait resolver.
2018-10-13 16:43:12 +02:00
"graphviz 0.0.0",
Update cargo
2019-03-29 04:13:13 +01:00
"jobserver 0.1.13 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock
2019-02-27 15:17:12 +01:00
"lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update parking_lot to 0.7 Unfortunately this'll dupe parking_lot until the data_structures crate is published and be updated in rls in conjunction with crossbeam-channel
2019-02-22 13:49:19 +01:00
"parking_lot 0.7.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update rustc-hash to hash up to 8 bytes at once with FxHasher
2018-05-24 05:37:40 +02:00
"rustc-hash 1.0.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock
2019-02-27 15:17:12 +01:00
"rustc-rayon 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)",
"rustc-rayon-core 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)",
rustc_target: move in syntax::abi and flip dependency.
2018-04-25 18:30:39 +02:00
"rustc_cratesio_shim 0.0.0",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"serialize 0.0.0",
Upgrade `smallvec` to 0.6.7 and use the new `may_dangle` feature.
2018-11-28 22:52:22 +01:00
"smallvec 0.6.7 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"stable_deref_trait 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
]
[[package]]
name = "rustc_driver"
version = "0.0.0"
dependencies = [
"arena 0.0.0",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"env_logger 0.5.13 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"graphviz 0.0.0",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"rustc 0.0.0",
Update Cargo.lock
2019-02-27 15:17:12 +01:00
"rustc-rayon 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)",
rustc: Implement the #[global_allocator] attribute This PR is an implementation of [RFC 1974] which specifies a new method of defining a global allocator for a program. This obsoletes the old `#![allocator]` attribute and also removes support for it. [RFC 1974]: https://github.com/rust-lang/rfcs/pull/197 The new `#[global_allocator]` attribute solves many issues encountered with the `#![allocator]` attribute such as composition and restrictions on the crate graph itself. The compiler now has much more control over the ABI of the allocator and how it's implemented, allowing much more freedom in terms of how this feature is implemented. cc #27389
2017-06-03 23:54:08 +02:00
"rustc_allocator 0.0.0",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"rustc_borrowck 0.0.0",
Rename trans to codegen everywhere.
2018-05-08 15:10:16 +02:00
"rustc_codegen_utils 0.0.0",
Add rustc_data_structures to rustc_driver dependencies.
2016-10-29 03:26:01 +02:00
"rustc_data_structures 0.0.0",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"rustc_errors 0.0.0",
"rustc_incremental 0.0.0",
Introduce rustc_interface and move some methods there
2018-12-08 20:30:23 +01:00
"rustc_interface 0.0.0",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"rustc_lint 0.0.0",
"rustc_metadata 0.0.0",
"rustc_mir 0.0.0",
"rustc_passes 0.0.0",
"rustc_plugin 0.0.0",
"rustc_privacy 0.0.0",
"rustc_resolve 0.0.0",
"rustc_save_analysis 0.0.0",
Rename rustc_back::target to rustc_target::spec.
2017-12-08 20:18:21 +01:00
"rustc_target 0.0.0",
introduce `infcx.at(..).normalize(..)` operation [VIC] It is backed by the new `normalize_projection_ty` query, which uses canonicalization.
2018-02-25 16:58:54 +01:00
"rustc_traits 0.0.0",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"rustc_typeck 0.0.0",
update Cargo.lock
2019-02-26 11:15:52 +01:00
"scoped-tls 1.0.0 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"serialize 0.0.0",
Upgrade `smallvec` to 0.6.7 and use the new `may_dangle` feature.
2018-11-28 22:52:22 +01:00
"smallvec 0.6.7 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"syntax 0.0.0",
"syntax_ext 0.0.0",
"syntax_pos 0.0.0",
]
[[package]]
name = "rustc_errors"
version = "0.0.0"
dependencies = [
revert accidental atty downgrade
2018-07-27 15:10:52 +02:00
"atty 0.2.11 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Breaking change upgrades
2018-08-05 00:24:39 +02:00
"rustc_cratesio_shim 0.0.0",
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
"rustc_data_structures 0.0.0",
store typeck lints in the `TypeckTables` Otherwise they are a "hidden output"
2017-01-29 00:13:21 +01:00
"serialize 0.0.0",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"syntax_pos 0.0.0",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"termcolor 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)",
Bootstrap from 1.28.0-beta.3
2018-06-22 17:48:43 +02:00
"unicode-width 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
]
Move rustc::util::fs into separate (new) crate
2018-08-03 23:31:03 +02:00
[[package]]
name = "rustc_fs_util"
version = "0.0.0"
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
[[package]]
name = "rustc_incremental"
version = "0.0.0"
dependencies = [
"graphviz 0.0.0",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update rand version
2019-03-04 08:20:46 +01:00
"rand 0.6.1 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"rustc 0.0.0",
"rustc_data_structures 0.0.0",
Move rustc::util::fs into separate (new) crate
2018-08-03 23:31:03 +02:00
"rustc_fs_util 0.0.0",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"serialize 0.0.0",
"syntax 0.0.0",
"syntax_pos 0.0.0",
]
Introduce rustc_interface and move some methods there
2018-12-08 20:30:23 +01:00
[[package]]
name = "rustc_interface"
version = "0.0.0"
dependencies = [
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
"rustc 0.0.0",
Update Cargo.lock
2019-02-27 15:17:12 +01:00
"rustc-rayon 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)",
Introduce rustc_interface and move some methods there
2018-12-08 20:30:23 +01:00
"rustc_allocator 0.0.0",
"rustc_borrowck 0.0.0",
"rustc_codegen_utils 0.0.0",
"rustc_data_structures 0.0.0",
"rustc_errors 0.0.0",
"rustc_incremental 0.0.0",
"rustc_lint 0.0.0",
"rustc_metadata 0.0.0",
"rustc_mir 0.0.0",
"rustc_passes 0.0.0",
"rustc_plugin 0.0.0",
"rustc_privacy 0.0.0",
"rustc_resolve 0.0.0",
"rustc_traits 0.0.0",
"rustc_typeck 0.0.0",
librustc_interface: Update scoped-tls to 1.0 Done previously as a part of https://github.com/rust-lang/rust/pull/58748
2019-03-01 10:18:50 +01:00
"scoped-tls 1.0.0 (registry+https://github.com/rust-lang/crates.io-index)",
Introduce rustc_interface and move some methods there
2018-12-08 20:30:23 +01:00
"serialize 0.0.0",
"smallvec 0.6.7 (registry+https://github.com/rust-lang/crates.io-index)",
"syntax 0.0.0",
"syntax_ext 0.0.0",
"syntax_pos 0.0.0",
]
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
[[package]]
name = "rustc_lint"
version = "0.0.0"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"rustc 0.0.0",
Use type safe `VariantIdx` instead of `usize` everywhere
2018-11-01 19:03:38 +01:00
"rustc_data_structures 0.0.0",
rustc_target: move in syntax::abi and flip dependency.
2018-04-25 18:30:39 +02:00
"rustc_target 0.0.0",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"syntax 0.0.0",
"syntax_pos 0.0.0",
]
[[package]]
name = "rustc_llvm"
version = "0.0.0"
dependencies = [
"build_helper 0.1.0",
Update cc crate to include Armv8-M changes
2019-01-09 15:51:22 +01:00
"cc 1.0.28 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
]
sanitizer support
2016-12-30 05:28:11 +01:00
[[package]]
name = "rustc_lsan"
version = "0.0.0"
dependencies = [
rustc: Implement the #[global_allocator] attribute This PR is an implementation of [RFC 1974] which specifies a new method of defining a global allocator for a program. This obsoletes the old `#![allocator]` attribute and also removes support for it. [RFC 1974]: https://github.com/rust-lang/rfcs/pull/197 The new `#[global_allocator]` attribute solves many issues encountered with the `#![allocator]` attribute such as composition and restrictions on the crate graph itself. The compiler now has much more control over the ABI of the allocator and how it's implemented, allowing much more freedom in terms of how this feature is implemented. cc #27389
2017-06-03 23:54:08 +02:00
"alloc 0.0.0",
use helper function in the rebuild logic of the rustc_*san crates
2017-02-05 02:10:29 +01:00
"build_helper 0.1.0",
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"cmake 0.1.33 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"compiler_builtins 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)",
sanitizer support
2016-12-30 05:28:11 +01:00
"core 0.0.0",
]
Update Cargo.lock
2019-03-01 01:22:10 +01:00
[[package]]
name = "rustc_macros"
version = "0.1.0"
dependencies = [
Add no_hash to query macro and move some queries over
2019-03-20 16:06:09 +01:00
"itertools 0.8.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock
2019-03-01 01:22:10 +01:00
"proc-macro2 0.4.24 (registry+https://github.com/rust-lang/crates.io-index)",
"quote 0.6.10 (registry+https://github.com/rust-lang/crates.io-index)",
"syn 0.15.22 (registry+https://github.com/rust-lang/crates.io-index)",
"synstructure 0.10.1 (registry+https://github.com/rust-lang/crates.io-index)",
]
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
[[package]]
name = "rustc_metadata"
version = "0.0.0"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"flate2 1.0.6 (registry+https://github.com/rust-lang/crates.io-index)",
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Use `Mmap` to open the rmeta file. Because those files are quite large, contribute significantly to peak memory usage, but only a small fraction of the data is ever read.
2018-10-31 22:59:32 +01:00
"memmap 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"rustc 0.0.0",
"rustc_data_structures 0.0.0",
"rustc_errors 0.0.0",
Rename rustc_back::target to rustc_target::spec.
2017-12-08 20:18:21 +01:00
"rustc_target 0.0.0",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"serialize 0.0.0",
Use `Mmap` to open the rmeta file. Because those files are quite large, contribute significantly to peak memory usage, but only a small fraction of the data is ever read.
2018-10-31 22:59:32 +01:00
"stable_deref_trait 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"syntax 0.0.0",
rustbuild: Use `cargo metadata` to learn about DAG This updates the commit to use workspaces to use `cargo metadata` instead of hardcoded lists about what to test. This should help us be resilient to updates in the future on behalf of the crate DAG and minimize the amount of files that need to be touched.
2016-10-07 08:30:38 +02:00
"syntax_ext 0.0.0",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"syntax_pos 0.0.0",
]
[[package]]
name = "rustc_mir"
version = "0.0.0"
dependencies = [
Regenerate tests
2018-03-05 10:21:11 +01:00
"arena 0.0.0",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"byteorder 1.2.7 (registry+https://github.com/rust-lang/crates.io-index)",
Use polonius_output
2018-05-29 13:54:15 +02:00
"either 1.5.0 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"graphviz 0.0.0",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"log_settings 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)",
adopt polonius-engine 0.6.2 Also datafrog 2.0.1, which works around a rustdoc bug
2019-01-02 20:45:22 +01:00
"polonius-engine 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"rustc 0.0.0",
Move large chunks of miri from rustc::mir::interpret to rustc_mir::interpret
2017-12-12 17:14:49 +01:00
"rustc_apfloat 0.0.0",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"rustc_data_structures 0.0.0",
Move borrowck error msg construction to module in `rustc_mir` (for later reuse by mir borrowck). post-rebase: Do not put "(Ast)" suffix in error msg unless passed `-Z borrowck-mir`. (But unconditionally include "(Mir)" suffix for mir-borrowck errors.)
2017-07-03 17:25:03 +02:00
"rustc_errors 0.0.0",
Rename rustc_back::target to rustc_target::spec.
2017-12-08 20:18:21 +01:00
"rustc_target 0.0.0",
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
"serialize 0.0.0",
Upgrade `smallvec` to 0.6.7 and use the new `may_dangle` feature.
2018-11-28 22:52:22 +01:00
"smallvec 0.6.7 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"syntax 0.0.0",
"syntax_pos 0.0.0",
]
sanitizer support
2016-12-30 05:28:11 +01:00
[[package]]
name = "rustc_msan"
version = "0.0.0"
dependencies = [
rustc: Implement the #[global_allocator] attribute This PR is an implementation of [RFC 1974] which specifies a new method of defining a global allocator for a program. This obsoletes the old `#![allocator]` attribute and also removes support for it. [RFC 1974]: https://github.com/rust-lang/rfcs/pull/197 The new `#[global_allocator]` attribute solves many issues encountered with the `#![allocator]` attribute such as composition and restrictions on the crate graph itself. The compiler now has much more control over the ABI of the allocator and how it's implemented, allowing much more freedom in terms of how this feature is implemented. cc #27389
2017-06-03 23:54:08 +02:00
"alloc 0.0.0",
use helper function in the rebuild logic of the rustc_*san crates
2017-02-05 02:10:29 +01:00
"build_helper 0.1.0",
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"cmake 0.1.33 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"compiler_builtins 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)",
sanitizer support
2016-12-30 05:28:11 +01:00
"core 0.0.0",
]
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
[[package]]
name = "rustc_passes"
version = "0.0.0"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"rustc 0.0.0",
Replace Rc with Lrc for shared data
2018-02-27 17:11:14 +01:00
"rustc_data_structures 0.0.0",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"rustc_errors 0.0.0",
Regenerate tests
2018-03-05 10:21:11 +01:00
"rustc_mir 0.0.0",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"syntax 0.0.0",
Conditionally skip two passes if their related attributes were not found
2019-01-17 07:28:39 +01:00
"syntax_ext 0.0.0",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"syntax_pos 0.0.0",
]
[[package]]
name = "rustc_plugin"
version = "0.0.0"
dependencies = [
"rustc 0.0.0",
"rustc_errors 0.0.0",
"rustc_metadata 0.0.0",
"syntax 0.0.0",
"syntax_pos 0.0.0",
]
[[package]]
name = "rustc_privacy"
version = "0.0.0"
dependencies = [
Fixup code
2019-01-14 00:07:42 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"rustc 0.0.0",
Replace Rc with Lrc for shared data
2018-02-27 17:11:14 +01:00
"rustc_data_structures 0.0.0",
Use recorded types in rustc_privacy
2017-09-16 15:45:49 +02:00
"rustc_typeck 0.0.0",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"syntax 0.0.0",
"syntax_pos 0.0.0",
]
[[package]]
name = "rustc_resolve"
version = "0.0.0"
dependencies = [
"arena 0.0.0",
Reapply the macro_rules disambiguation changes from master
2018-10-04 12:41:58 +02:00
"bitflags 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"rustc 0.0.0",
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
"rustc_data_structures 0.0.0",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"rustc_errors 0.0.0",
Store concrete crate stores where possible
2018-07-31 23:23:31 +02:00
"rustc_metadata 0.0.0",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"syntax 0.0.0",
"syntax_pos 0.0.0",
]
[[package]]
name = "rustc_save_analysis"
version = "0.0.0"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock
2019-02-18 10:32:58 +01:00
"rls-data 0.18.2 (registry+https://github.com/rust-lang/crates.io-index)",
"rls-span 0.4.1 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"rustc 0.0.0",
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
"rustc-serialize 0.3.24 (registry+https://github.com/rust-lang/crates.io-index)",
Emit only necessary compilation options in save-analysis This is `command`, `directory` and `output` file.
2018-09-22 23:19:39 +02:00
"rustc_codegen_utils 0.0.0",
review changes
2017-08-01 04:43:11 +02:00
"rustc_data_structures 0.0.0",
rustc_target: move in syntax::abi and flip dependency.
2018-04-25 18:30:39 +02:00
"rustc_target 0.0.0",
convert save-analysis to use `ItemCtxt` and not `ast_ty_to_ty_cache`
2017-05-03 18:18:04 +02:00
"rustc_typeck 0.0.0",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"syntax 0.0.0",
"syntax_pos 0.0.0",
]
Rename rustc_back::target to rustc_target::spec.
2017-12-08 20:18:21 +01:00
[[package]]
name = "rustc_target"
version = "0.0.0"
dependencies = [
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"bitflags 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
rustc_target: move in syntax::abi and flip dependency.
2018-04-25 18:30:39 +02:00
"rustc_cratesio_shim 0.0.0",
Use IndexVec instead of `usize` in librustc
2018-11-01 16:01:24 +01:00
"rustc_data_structures 0.0.0",
Rename rustc_back::target to rustc_target::spec.
2017-12-08 20:18:21 +01:00
"serialize 0.0.0",
]
Directly reference the roadmap upstream
2019-03-04 18:29:23 +01:00
[[package]]
name = "rustc_term"
version = "0.0.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
update clippy submodule updates to cafef7b576203f166add9ed143979d9775c25219
2018-09-07 09:12:06 +02:00
[[package]]
name = "rustc_tools_util"
Update Cargo.lock
2019-01-10 13:42:14 +01:00
version = "0.1.1"
submodules: update clippy from 39bd8449 to c63b6349 Changes: ```` Revert "tests: used_underscore_binding_macro: disable random_state lint." Revert "Auto merge of #3603 - xfix:random-state-lint, r=phansch" rustup https://github.com/rust-lang/rust/pull/56837 rustup (don't know the exact PR unfortunately) Add itertools to integration tests tests: used_underscore_binding_macro: disable random_state lint. Trigger `use_self` lint in local macros Add run-rustfix where it already passes rustup: https://github.com/rust-lang/rust/pull/55517 Make clippy work with parallel rustc Add ui/for_kv_map test for false positive in #1279 Update to latest compiletest-rs release add testcase for #3462 deps: bump rustc_tools_util version from 0.1.0 to 0.1.1 just in case... Use compiletest's aux-build header instead of include macro rustc_tool_utils: fix failure to create proper non-repo version string when used in crates on crates.io, bump version rustfmt UI test cleanup: Extract ifs_same_cond tests Extract IteratorFalsePositives into option_helpers.rs UI test cleanup: Extract for_kv_map lint tests UI test cleanup: Extract lint from methods.rs test Fix test for rust-lang/rust#57250 Limit infinite_iter collect() check to known types Some improvements to util documentation Use hashset for name blacklist Reformat random_state tests Use node_id_to_type_opt instead of node_it_to_type in random_state Check pattern equality while checking declaration equality random_state lint Move constant write checks to temporary_assignment lint Use an FxHashSet for valid idents in documentation lint Fix suggestion for unnecessary_ref lint Update CONTRIBUTING.md for rustfix tests Update .fixed files via update-references.sh Run rustfix on first UI test Use WIP branch for compiletest_rs ````
2019-01-05 15:40:10 +01:00
[[package]]
name = "rustc_tools_util"
Update Cargo.lock
2019-01-10 13:42:14 +01:00
version = "0.1.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
update clippy submodule updates to cafef7b576203f166add9ed143979d9775c25219
2018-09-07 09:12:06 +02:00
introduce `infcx.at(..).normalize(..)` operation [VIC] It is backed by the new `normalize_projection_ty` query, which uses canonicalization.
2018-02-25 16:58:54 +01:00
[[package]]
name = "rustc_traits"
version = "0.0.0"
dependencies = [
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"bitflags 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)",
Handle sub-typing in chalk-engine
2018-11-28 22:11:00 +01:00
"chalk-engine 0.9.0 (registry+https://github.com/rust-lang/crates.io-index)",
introduce `infcx.at(..).normalize(..)` operation [VIC] It is backed by the new `normalize_projection_ty` query, which uses canonicalization.
2018-02-25 16:58:54 +01:00
"graphviz 0.0.0",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
introduce `infcx.at(..).normalize(..)` operation [VIC] It is backed by the new `normalize_projection_ty` query, which uses canonicalization.
2018-02-25 16:58:54 +01:00
"rustc 0.0.0",
"rustc_data_structures 0.0.0",
Provide program clauses for builtin types
2018-10-31 22:07:54 +01:00
"rustc_target 0.0.0",
Upgrade `smallvec` to 0.6.7 and use the new `may_dangle` feature.
2018-11-28 22:52:22 +01:00
"smallvec 0.6.7 (registry+https://github.com/rust-lang/crates.io-index)",
introduce `infcx.at(..).normalize(..)` operation [VIC] It is backed by the new `normalize_projection_ty` query, which uses canonicalization.
2018-02-25 16:58:54 +01:00
"syntax 0.0.0",
"syntax_pos 0.0.0",
]
sanitizer support
2016-12-30 05:28:11 +01:00
[[package]]
name = "rustc_tsan"
version = "0.0.0"
dependencies = [
Move unused-extern-crate to late pass
2017-06-24 10:48:27 +02:00
"alloc 0.0.0",
use helper function in the rebuild logic of the rustc_*san crates
2017-02-05 02:10:29 +01:00
"build_helper 0.1.0",
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"cmake 0.1.33 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"compiler_builtins 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)",
sanitizer support
2016-12-30 05:28:11 +01:00
"core 0.0.0",
]
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
[[package]]
name = "rustc_typeck"
version = "0.0.0"
dependencies = [
"arena 0.0.0",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"rustc 0.0.0",
update Cargo.lock
2016-11-18 11:31:44 +01:00
"rustc_data_structures 0.0.0",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"rustc_errors 0.0.0",
rustc_target: move in syntax::abi and flip dependency.
2018-04-25 18:30:39 +02:00
"rustc_target 0.0.0",
Upgrade `smallvec` to 0.6.7 and use the new `may_dangle` feature.
2018-11-28 22:52:22 +01:00
"smallvec 0.6.7 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"syntax 0.0.0",
"syntax_pos 0.0.0",
]
Update the clippy and miri submodules
2018-05-11 14:11:06 +02:00
[[package]]
name = "rustc_version"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "0.2.3"
Update the clippy and miri submodules
2018-05-11 14:11:06 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"semver 0.9.0 (registry+https://github.com/rust-lang/crates.io-index)",
]
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
[[package]]
name = "rustdoc"
version = "0.0.0"
dependencies = [
Update minifier version
2019-01-25 00:07:08 +01:00
"minifier 0.0.28 (registry+https://github.com/rust-lang/crates.io-index)",
Update parking_lot to 0.7 Unfortunately this'll dupe parking_lot until the data_structures crate is published and be updated in rls in conjunction with crossbeam-channel
2019-02-22 13:49:19 +01:00
"parking_lot 0.7.1 (registry+https://github.com/rust-lang/crates.io-index)",
bump pulldown
2018-02-18 22:33:56 +01:00
"pulldown-cmark 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"tempfile 3.0.5 (registry+https://github.com/rust-lang/crates.io-index)",
Build rustdoc on-demand. Rustdoc is no longer compiled in every stage, alongside rustc, instead it is only compiled when requested, and generally only for the last stage.
2017-07-23 04:01:58 +02:00
]
Convert python script to rust
2018-02-05 23:43:53 +01:00
[[package]]
name = "rustdoc-themes"
version = "0.1.0"
Build rustdoc on-demand. Rustdoc is no longer compiled in every stage, alongside rustc, instead it is only compiled when requested, and generally only for the last stage.
2017-07-23 04:01:58 +02:00
[[package]]
name = "rustdoc-tool"
version = "0.0.0"
dependencies = [
"rustdoc 0.0.0",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
]
test: Make a dedicated testsuite for rustfix This commit adds a dedicated mode to compiletest for running rustfix tests, adding a new `src/test/rustfix` directory which will execute all tests as a "rustfix" test, namely requiring that a `*.fixed` is next to the main file which is the result of the rustfix project's application of fixes. The `rustfix` crate is pulled in to actually perform the fixing, and the rustfix compiletest mode will assert a few properties about the fixing: * The expected fixed output must be the same as rustc's output suggestions applied to the original code. * The fixed code must compile successfully * The fixed code must have no further diagnostics emitted about it
2018-05-02 17:43:15 +02:00
[[package]]
name = "rustfix"
Update cargo, rls, miri
2018-12-17 19:23:04 +01:00
version = "0.4.4"
Update Cargo submodule
2018-07-17 18:04:22 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update cargo
2019-02-03 23:42:29 +01:00
"failure 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo, rls, miri
2018-12-17 19:23:04 +01:00
"serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"serde_derive 1.0.81 (registry+https://github.com/rust-lang/crates.io-index)",
"serde_json 1.0.33 (registry+https://github.com/rust-lang/crates.io-index)",
test: Make a dedicated testsuite for rustfix This commit adds a dedicated mode to compiletest for running rustfix tests, adding a new `src/test/rustfix` directory which will execute all tests as a "rustfix" test, namely requiring that a `*.fixed` is next to the main file which is the result of the rustfix project's application of fixes. The `rustfix` crate is pulled in to actually perform the fixing, and the rustfix compiletest mode will assert a few properties about the fixing: * The expected fixed output must be the same as rustc's output suggestions applied to the original code. * The fixed code must compile successfully * The fixed code must have no further diagnostics emitted about it
2018-05-02 17:43:15 +02:00
]
cargo update and add miri as the rustc workspace member.
2017-12-15 20:41:58 +01:00
[[package]]
name = "rustfmt-nightly"
Update rustfmt to 1.2.0
2019-03-27 02:37:01 +01:00
version = "1.2.0"
cargo update and add miri as the rustc workspace member.
2017-12-15 20:41:58 +01:00
dependencies = [
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"atty 0.2.11 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock
2019-02-18 10:32:58 +01:00
"bytecount 0.5.1 (registry+https://github.com/rust-lang/crates.io-index)",
"cargo_metadata 0.7.1 (registry+https://github.com/rust-lang/crates.io-index)",
Reduce the numbers of syn versions compiled from 4 to 2 The last remaining one comes from mdbook. Unfortunately updating it breaks everything
2018-12-08 15:11:47 +01:00
"derive-new 0.5.6 (registry+https://github.com/rust-lang/crates.io-index)",
cargo update and add miri as the rustc workspace member.
2017-12-15 20:41:58 +01:00
"diff 0.1.11 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock
2019-02-18 10:32:58 +01:00
"dirs 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)",
"env_logger 0.6.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo
2019-02-03 23:42:29 +01:00
"failure 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)",
Bump to 1.27.0 Also update some `Cargo.lock` dependencies, finishing up some final steps of our [release process]! This doesn't update the bootstrap compiler just yet but that will come in a follow-up PR. [release process]: https://forge.rust-lang.org/release-process.html
2018-04-02 17:43:55 +02:00
"getopts 0.2.17 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock
2019-02-18 10:32:58 +01:00
"itertools 0.8.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS
2018-12-10 08:58:08 +01:00
"lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
"regex 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Clippy, RLS and Rustfmt
2019-03-18 18:34:18 +01:00
"rustc-ap-rustc_target 407.0.0 (registry+https://github.com/rust-lang/crates.io-index)",
"rustc-ap-syntax 407.0.0 (registry+https://github.com/rust-lang/crates.io-index)",
"rustc-ap-syntax_pos 407.0.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS
2018-12-10 08:58:08 +01:00
"rustc-workspace-hack 1.0.0",
Update cargo, rls, miri
2018-12-17 19:23:04 +01:00
"serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"serde_derive 1.0.81 (registry+https://github.com/rust-lang/crates.io-index)",
"serde_json 1.0.33 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS
2018-12-10 08:58:08 +01:00
"term 0.5.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"toml 0.4.10 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS
2018-12-10 08:58:08 +01:00
"unicode-segmentation 1.2.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock
2019-02-18 10:32:58 +01:00
"unicode-width 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)",
"unicode_categories 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS
2018-12-10 08:58:08 +01:00
]
Update Cargo's submodule Bring in a few updates and fixes, mostly a standard update.
2018-09-28 20:27:30 +02:00
[[package]]
name = "rusty-fork"
version = "0.2.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"fnv 1.0.6 (registry+https://github.com/rust-lang/crates.io-index)",
"quick-error 1.2.2 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"tempfile 3.0.5 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo's submodule Bring in a few updates and fixes, mostly a standard update.
2018-09-28 20:27:30 +02:00
"wait-timeout 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)",
]
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
[[package]]
name = "ryu"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "0.2.7"
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Update Cargo and its dependencies This'll probably have a bunch of build errors, so let's try and head those off and find them sooner rather than later!
2018-01-08 22:56:22 +01:00
[[package]]
name = "same-file"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "1.0.4"
Update Cargo and its dependencies This'll probably have a bunch of build errors, so let's try and head those off and find them sooner rather than later!
2018-01-08 22:56:22 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"winapi-util 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo and its dependencies This'll probably have a bunch of build errors, so let's try and head those off and find them sooner rather than later!
2018-01-08 22:56:22 +01:00
]
[[package]]
name = "schannel"
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
version = "0.1.14"
Update Cargo and its dependencies This'll probably have a bunch of build errors, so let's try and head those off and find them sooner rather than later!
2018-01-08 22:56:22 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update RLS
2018-12-10 08:58:08 +01:00
"lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo and its dependencies This'll probably have a bunch of build errors, so let's try and head those off and find them sooner rather than later!
2018-01-08 22:56:22 +01:00
]
update Cargo.lock
2019-02-26 11:15:52 +01:00
[[package]]
name = "scoped-tls"
version = "1.0.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
Update Cargo.lock
2019-02-18 10:32:58 +01:00
[[package]]
name = "scoped_threadpool"
version = "0.1.9"
source = "registry+https://github.com/rust-lang/crates.io-index"
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
[[package]]
name = "scopeguard"
version = "0.3.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
Update Cargo and its dependencies This'll probably have a bunch of build errors, so let's try and head those off and find them sooner rather than later!
2018-01-08 22:56:22 +01:00
[[package]]
name = "semver"
version = "0.9.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"semver-parser 0.7.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo, rls, miri
2018-12-17 19:23:04 +01:00
"serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)",
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
]
[[package]]
name = "semver-parser"
version = "0.7.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
[[package]]
name = "serde"
Update cargo, rls, miri
2018-12-17 19:23:04 +01:00
version = "1.0.82"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Update cargo, rls, miri
2018-12-17 19:23:04 +01:00
dependencies = [
"serde_derive 1.0.81 (registry+https://github.com/rust-lang/crates.io-index)",
]
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
[[package]]
name = "serde_derive"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "1.0.81"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update RLS and Rustfmt
2018-11-19 05:21:10 +01:00
"proc-macro2 0.4.24 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"quote 0.6.10 (registry+https://github.com/rust-lang/crates.io-index)",
"syn 0.15.22 (registry+https://github.com/rust-lang/crates.io-index)",
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
]
[[package]]
name = "serde_ignored"
rustbuild: Switch back to using hard links The `copy` function historically in rustbuild used hard links to speed up the copy operations that it does. This logic was backed out, however, in #39518 due to a bug that only showed up on Windows, described in #39504. The cause described in #39504 happened because Cargo, on a fresh build, would overwrite the previous artifacts with new hard links that Cargo itself manages. This behavior in Cargo was fixed in rust-lang/cargo#4390 where it no longer should overwrite files on fresh builds, opportunistically leaving the filesystem intact and not touching it. Hopefully this can help speed up local builds by doing fewer copies all over the place!
2017-09-02 05:46:51 +02:00
version = "0.0.4"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update cargo, rls, miri
2018-12-17 19:23:04 +01:00
"serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)",
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
]
Update dependencies In order to update mdbook, we have to update other stuff too.
2017-02-20 01:20:57 +01:00
[[package]]
name = "serde_json"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "1.0.33"
Update dependencies In order to update mdbook, we have to update other stuff too.
2017-02-20 01:20:57 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo's submodule Bring in a few updates and fixes, mostly a standard update.
2018-09-28 20:27:30 +02:00
"itoa 0.4.3 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"ryu 0.2.7 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo, rls, miri
2018-12-17 19:23:04 +01:00
"serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)",
Update dependencies In order to update mdbook, we have to update other stuff too.
2017-02-20 01:20:57 +01:00
]
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
[[package]]
name = "serialize"
version = "0.0.0"
Use optimized SmallVec implementation
2018-08-13 21:15:16 +02:00
dependencies = [
Upgrade `smallvec` to 0.6.7 and use the new `may_dangle` feature.
2018-11-28 22:52:22 +01:00
"smallvec 0.6.7 (registry+https://github.com/rust-lang/crates.io-index)",
Use optimized SmallVec implementation
2018-08-13 21:15:16 +02:00
]
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
Update to newer version of mdbook(2)
2019-01-19 03:39:37 +01:00
[[package]]
name = "sha-1"
version = "0.7.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"block-buffer 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)",
"byte-tools 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
"digest 0.7.6 (registry+https://github.com/rust-lang/crates.io-index)",
"fake-simd 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)",
]
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
[[package]]
name = "shell-escape"
Bump to 1.27.0 Also update some `Cargo.lock` dependencies, finishing up some final steps of our [release process]! This doesn't update the bootstrap compiler just yet but that will come in a follow-up PR. [release process]: https://forge.rust-lang.org/release-process.html
2018-04-02 17:43:55 +02:00
version = "0.1.4"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
update mdbook to 0.1.2 and improve printing of errors
2018-01-25 18:32:25 +01:00
[[package]]
name = "shlex"
version = "0.1.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
[[package]]
name = "signal-hook"
version = "0.1.7"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"arc-swap 0.3.7 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
]
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
[[package]]
name = "siphasher"
version = "0.2.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
[[package]]
name = "slab"
version = "0.4.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
Add sync module to rustc_data_structures
2017-12-03 13:49:01 +01:00
[[package]]
name = "smallvec"
Upgrade `smallvec` to 0.6.7 and use the new `may_dangle` feature.
2018-11-28 22:52:22 +01:00
version = "0.6.7"
Add sync module to rustc_data_structures
2017-12-03 13:49:01 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Update the Cargo submodule and rustfix Should hopefully bring in a few more `cargo fix`-related fixes.
2018-07-26 02:25:12 +02:00
dependencies = [
"unreachable 1.0.0 (registry+https://github.com/rust-lang/crates.io-index)",
]
Add sync module to rustc_data_structures
2017-12-03 13:49:01 +01:00
Update Cargo
2017-06-26 18:26:15 +02:00
[[package]]
name = "socket2"
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
version = "0.3.8"
Update Cargo
2017-06-26 18:26:15 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"cfg-if 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"redox_syscall 0.1.43 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo
2017-06-26 18:26:15 +02:00
]
Remove rustc_llvm dependency from rustc_metadata Move the code for loading metadata from rlibs and dylibs from rustc_metadata into rustc_trans, and introduce a trait to avoid introducing a direct dependency on rustc_trans. This means rustc_metadata is no longer rebuilt when LLVM changes.
2017-04-26 23:22:45 +02:00
[[package]]
name = "stable_deref_trait"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
version = "1.1.0"
Remove rustc_llvm dependency from rustc_metadata Move the code for loading metadata from rlibs and dylibs from rustc_metadata into rustc_trans, and introduce a trait to avoid introducing a direct dependency on rustc_trans. This means rustc_metadata is no longer rebuilt when LLVM changes.
2017-04-26 23:22:45 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
[[package]]
name = "std"
version = "0.0.0"
dependencies = [
"alloc 0.0.0",
std: Use backtrace-sys from crates.io This commit switches the standard library to using the `backtrace-sys` crate from crates.io instead of duplicating the logic here in the Rust repositor with the `backtrace-sys`'s crate's logic. Eventually this will hopefully be a good step towards using the `backtrace` crate directly from crates.io itself, but we're not quite there yet! Hopefully this is a small incremental first step we can take.
2018-12-15 01:47:18 +01:00
"backtrace-sys 0.1.27 (registry+https://github.com/rust-lang/crates.io-index)",
lock after rebase
2019-01-17 11:22:48 +01:00
"cc 1.0.28 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"compiler_builtins 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"core 0.0.0",
Update dlmalloc to 0.1.3
2019-02-26 01:18:22 +01:00
"dlmalloc 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)",
Add `std::os::fortanix_sgx` module
2018-12-19 12:56:17 +01:00
"fortanix-sgx-abi 0.3.2 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"panic_abort 0.0.0",
"panic_unwind 0.0.0",
Add profiling support, through the rustc -Z profile flag. When -Z profile is passed, the GCDAProfiling LLVM pass is added to the pipeline, which uses debug information to instrument the IR. After compiling with -Z profile, the $(OUT_DIR)/$(CRATE_NAME).gcno file is created, containing initial profiling information. After running the program built, the $(OUT_DIR)/$(CRATE_NAME).gcda file is created, containing branch counters. The created *.gcno and *.gcda files can be processed using the "llvm-cov gcov" and "lcov" tools. The profiling data LLVM generates does not faithfully follow the GCC's format for *.gcno and *.gcda files, and so it will probably not work with other tools (such as gcov itself) that consume these files.
2017-02-13 10:57:50 +01:00
"profiler_builtins 0.0.0",
std: Depend directly on crates.io crates 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-11-20 06:52:50 +01:00
"rand 0.6.1 (registry+https://github.com/rust-lang/crates.io-index)",
std: Use `rustc_demangle` from crates.io No more need to duplicate the demangling routine between crates.io and the standard library, we can use the exact same one!
2018-12-14 23:37:51 +01:00
"rustc-demangle 0.1.10 (registry+https://github.com/rust-lang/crates.io-index)",
sanitizer support
2016-12-30 05:28:11 +01:00
"rustc_asan 0.0.0",
"rustc_lsan 0.0.0",
"rustc_msan 0.0.0",
"rustc_tsan 0.0.0",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"unwind 0.0.0",
]
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
[[package]]
name = "string_cache"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
version = "0.7.3"
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update RLS
2018-12-10 08:58:08 +01:00
"lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"new_debug_unreachable 1.0.1 (registry+https://github.com/rust-lang/crates.io-index)",
"phf_shared 0.7.22 (registry+https://github.com/rust-lang/crates.io-index)",
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
"precomputed-hash 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo, rls, miri
2018-12-17 19:23:04 +01:00
"serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)",
Update string_cache_codegen to 0.4.2
2019-02-26 12:06:31 +01:00
"string_cache_codegen 0.4.2 (registry+https://github.com/rust-lang/crates.io-index)",
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
"string_cache_shared 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "string_cache_codegen"
Update string_cache_codegen to 0.4.2
2019-02-26 12:06:31 +01:00
version = "0.4.2"
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"phf_generator 0.7.22 (registry+https://github.com/rust-lang/crates.io-index)",
"phf_shared 0.7.22 (registry+https://github.com/rust-lang/crates.io-index)",
Update string_cache_codegen to 0.4.2
2019-02-26 12:06:31 +01:00
"proc-macro2 0.4.24 (registry+https://github.com/rust-lang/crates.io-index)",
"quote 0.6.10 (registry+https://github.com/rust-lang/crates.io-index)",
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
"string_cache_shared 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "string_cache_shared"
version = "0.3.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
[[package]]
name = "strsim"
Update Cargo This notably includes * https://github.com/rust-lang/cargo/pull/5152 * https://github.com/rust-lang/cargo/pull/5188 The first one switches cargo from docopt to clap ( we also update to the latest calp in this repository), the second one should help us to unify feature flags for Cargo itself and RLS, and build Cargo libray only once.
2018-03-16 11:37:14 +01:00
version = "0.7.0"
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Update MDBook
2018-04-21 23:06:13 +02:00
[[package]]
name = "strum"
Reduce the numbers of syn versions compiled from 4 to 2 The last remaining one comes from mdbook. Unfortunately updating it breaks everything
2018-12-08 15:11:47 +01:00
version = "0.11.0"
Update MDBook
2018-04-21 23:06:13 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
[[package]]
name = "strum_macros"
Reduce the numbers of syn versions compiled from 4 to 2 The last remaining one comes from mdbook. Unfortunately updating it breaks everything
2018-12-08 15:11:47 +01:00
version = "0.11.0"
Update MDBook
2018-04-21 23:06:13 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Reduce the numbers of syn versions compiled from 4 to 2 The last remaining one comes from mdbook. Unfortunately updating it breaks everything
2018-12-08 15:11:47 +01:00
"heck 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS and Rustfmt
2018-11-19 05:21:10 +01:00
"proc-macro2 0.4.24 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"quote 0.6.10 (registry+https://github.com/rust-lang/crates.io-index)",
"syn 0.15.22 (registry+https://github.com/rust-lang/crates.io-index)",
Update MDBook
2018-04-21 23:06:13 +02:00
]
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
[[package]]
name = "syn"
version = "0.11.11"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"quote 0.3.15 (registry+https://github.com/rust-lang/crates.io-index)",
"synom 0.11.3 (registry+https://github.com/rust-lang/crates.io-index)",
"unicode-xid 0.0.4 (registry+https://github.com/rust-lang/crates.io-index)",
]
Update RLS and Rustfmt
2018-11-19 05:21:10 +01:00
[[package]]
name = "syn"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "0.15.22"
Update RLS and Rustfmt
2018-11-19 05:21:10 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"proc-macro2 0.4.24 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"quote 0.6.10 (registry+https://github.com/rust-lang/crates.io-index)",
Bump to 1.27.0 Also update some `Cargo.lock` dependencies, finishing up some final steps of our [release process]! This doesn't update the bootstrap compiler just yet but that will come in a follow-up PR. [release process]: https://forge.rust-lang.org/release-process.html
2018-04-02 17:43:55 +02:00
"unicode-xid 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
]
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
[[package]]
name = "synom"
version = "0.11.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"unicode-xid 0.0.4 (registry+https://github.com/rust-lang/crates.io-index)",
]
Update Cargo and its dependencies Just a routine update!
2017-12-10 18:42:49 +01:00
[[package]]
name = "synstructure"
Reduce the numbers of syn versions compiled from 4 to 2 The last remaining one comes from mdbook. Unfortunately updating it breaks everything
2018-12-08 15:11:47 +01:00
version = "0.10.1"
Update Cargo and its dependencies Just a routine update!
2017-12-10 18:42:49 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update RLS and Rustfmt
2018-11-19 05:21:10 +01:00
"proc-macro2 0.4.24 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"quote 0.6.10 (registry+https://github.com/rust-lang/crates.io-index)",
"syn 0.15.22 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Bring in some fixes for `cargo fix` notably
2018-07-31 23:16:55 +02:00
"unicode-xid 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo and its dependencies Just a routine update!
2017-12-10 18:42:49 +01:00
]
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
[[package]]
name = "syntax"
version = "0.0.0"
dependencies = [
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"bitflags 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Change implementation of syntax::util::SmallVector to use data_structures::SmallVec.
2016-11-03 05:33:35 +01:00
"rustc_data_structures 0.0.0",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"rustc_errors 0.0.0",
rustc_target: move in syntax::abi and flip dependency.
2018-04-25 18:30:39 +02:00
"rustc_target 0.0.0",
update Cargo.lock
2019-02-26 11:15:52 +01:00
"scoped-tls 1.0.0 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"serialize 0.0.0",
Upgrade `smallvec` to 0.6.7 and use the new `may_dangle` feature.
2018-11-28 22:52:22 +01:00
"smallvec 0.6.7 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"syntax_pos 0.0.0",
]
[[package]]
name = "syntax_ext"
version = "0.0.0"
dependencies = [
"fmt_macros 0.0.0",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Replace Rc with Lrc for shared data
2018-02-27 17:11:14 +01:00
"rustc_data_structures 0.0.0",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"rustc_errors 0.0.0",
rustc_target: move in syntax::abi and flip dependency.
2018-04-25 18:30:39 +02:00
"rustc_target 0.0.0",
Upgrade `smallvec` to 0.6.7 and use the new `may_dangle` feature.
2018-11-28 22:52:22 +01:00
"smallvec 0.6.7 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"syntax 0.0.0",
"syntax_pos 0.0.0",
]
[[package]]
name = "syntax_pos"
version = "0.0.0"
dependencies = [
Allocate Symbol strings from an arena
2018-05-10 16:27:46 +02:00
"arena 0.0.0",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"cfg-if 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)",
Moved FileMap construction to it's own constructor. The rationale is that BOM stripping is needed for lazy source loading for external crates, and duplication can be avoided by moving the corresponding functionality to libsyntax_pos.
2017-06-10 16:09:51 +02:00
"rustc_data_structures 0.0.0",
update Cargo.lock
2019-02-26 11:15:52 +01:00
"scoped-tls 1.0.0 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
"serialize 0.0.0",
Bootstrap from 1.28.0-beta.3
2018-06-22 17:48:43 +02:00
"unicode-width 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
]
Update to the oxidized rust-installer
2017-05-09 00:01:13 +02:00
[[package]]
name = "tar"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "0.4.20"
Update to the oxidized rust-installer
2017-05-09 00:01:13 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"filetime 0.2.4 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"redox_syscall 0.1.43 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule
2018-07-17 18:04:22 +02:00
"xattr 0.2.2 (registry+https://github.com/rust-lang/crates.io-index)",
Update to the oxidized rust-installer
2017-05-09 00:01:13 +02:00
]
Update Cargo This includes rust-lang/cargo#5255 which fixed regression in `cargo rustdoc` command.
2018-03-29 09:34:55 +02:00
[[package]]
name = "tempfile"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "3.0.5"
Update Cargo This includes rust-lang/cargo#5255 which fixed regression in `cargo rustdoc` command.
2018-03-29 09:34:55 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"cfg-if 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"rand 0.6.1 (registry+https://github.com/rust-lang/crates.io-index)",
"redox_syscall 0.1.43 (registry+https://github.com/rust-lang/crates.io-index)",
Update the Cargo submodule
2018-04-18 17:43:59 +02:00
"remove_dir_all 0.5.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo This includes rust-lang/cargo#5255 which fixed regression in `cargo rustdoc` command.
2018-03-29 09:34:55 +02:00
]
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
[[package]]
name = "tendril"
version = "0.4.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"futf 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)",
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
"mac 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)",
"utf-8 0.7.2 (registry+https://github.com/rust-lang/crates.io-index)",
]
Update miri
2019-03-02 20:58:38 +01:00
[[package]]
name = "term"
version = "0.4.6"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"kernel32-sys 0.2.2 (registry+https://github.com/rust-lang/crates.io-index)",
"winapi 0.2.8 (registry+https://github.com/rust-lang/crates.io-index)",
]
Update rustfmt to 0.4.1
2018-03-19 15:14:13 +01:00
[[package]]
name = "term"
version = "0.5.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"byteorder 1.2.7 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update rustfmt to 0.4.1
2018-03-19 15:14:13 +01:00
]
Update the Cargo submodule and rustfix Should hopefully bring in a few more `cargo fix`-related fixes.
2018-07-26 02:25:12 +02:00
[[package]]
name = "termcolor"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "1.0.4"
Update the Cargo submodule and rustfix Should hopefully bring in a few more `cargo fix`-related fixes.
2018-07-26 02:25:12 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"wincolor 1.0.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update the Cargo submodule and rustfix Should hopefully bring in a few more `cargo fix`-related fixes.
2018-07-26 02:25:12 +02:00
]
Update cargo/rls submodules and dependencies Brings in a few regression fixes on the Cargo side, updates the rls to work with the newer Cargo, and also updates other crates.io dependencies to pull in various bug fixes and such.
2017-06-15 04:33:06 +02:00
[[package]]
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
name = "termion"
version = "1.5.1"
Update cargo/rls submodules and dependencies Brings in a few regression fixes on the Cargo side, updates the rls to work with the newer Cargo, and also updates other crates.io dependencies to pull in various bug fixes and such.
2017-06-15 04:33:06 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"redox_syscall 0.1.43 (registry+https://github.com/rust-lang/crates.io-index)",
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
"redox_termios 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo/rls submodules and dependencies Brings in a few regression fixes on the Cargo side, updates the rls to work with the newer Cargo, and also updates other crates.io dependencies to pull in various bug fixes and such.
2017-06-15 04:33:06 +02:00
]
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
[[package]]
name = "test"
version = "0.0.0"
dependencies = [
Directly reference the roadmap upstream
2019-03-04 18:29:23 +01:00
"libtest 0.0.1 (registry+https://github.com/rust-lang/crates.io-index)",
proc_macro: move to a dependency of libtest.
2018-03-20 19:43:33 +01:00
"proc_macro 0.0.0",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
]
Update miri
2019-03-02 20:58:38 +01:00
[[package]]
name = "tester"
version = "0.5.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"getopts 0.2.17 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update miri
2019-03-02 20:58:38 +01:00
"term 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
]
update crate dependencies I wanted to update mdbook's version. This ended up updating a bunch of other stuff too.
2017-06-27 19:33:32 +02:00
[[package]]
name = "textwrap"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
version = "0.10.0"
update crate dependencies I wanted to update mdbook's version. This ended up updating a bunch of other stuff too.
2017-06-27 19:33:32 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Bootstrap from 1.28.0-beta.3
2018-06-22 17:48:43 +02:00
"unicode-width 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)",
update crate dependencies I wanted to update mdbook's version. This ended up updating a bunch of other stuff too.
2017-06-27 19:33:32 +02:00
]
Add Cargo as a submodule
2017-02-15 23:55:26 +01:00
[[package]]
name = "thread_local"
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
version = "0.3.6"
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update RLS
2018-12-10 08:58:08 +01:00
"lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
]
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
[[package]]
name = "tidy"
version = "0.1.0"
Start adding a whitelist for rustc dependencies
2018-02-23 02:52:56 +01:00
dependencies = [
Update cargo, rls, miri
2018-12-17 19:23:04 +01:00
"serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"serde_derive 1.0.81 (registry+https://github.com/rust-lang/crates.io-index)",
"serde_json 1.0.33 (registry+https://github.com/rust-lang/crates.io-index)",
Start adding a whitelist for rustc dependencies
2018-02-23 02:52:56 +01:00
]
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
Update Cargo submodule to master Just a routine update
2018-01-25 05:01:42 +01:00
[[package]]
name = "time"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
version = "0.1.40"
Update Cargo submodule to master Just a routine update
2018-01-25 05:01:42 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"redox_syscall 0.1.43 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule to master Just a routine update
2018-01-25 05:01:42 +01:00
]
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
[[package]]
name = "tokio"
version = "0.1.14"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"bytes 0.4.11 (registry+https://github.com/rust-lang/crates.io-index)",
"futures 0.1.21 (registry+https://github.com/rust-lang/crates.io-index)",
"mio 0.6.16 (registry+https://github.com/rust-lang/crates.io-index)",
"num_cpus 1.8.0 (registry+https://github.com/rust-lang/crates.io-index)",
"tokio-codec 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)",
"tokio-current-thread 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)",
"tokio-executor 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)",
"tokio-fs 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)",
"tokio-io 0.1.11 (registry+https://github.com/rust-lang/crates.io-index)",
"tokio-reactor 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)",
"tokio-tcp 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)",
"tokio-threadpool 0.1.10 (registry+https://github.com/rust-lang/crates.io-index)",
"tokio-timer 0.2.8 (registry+https://github.com/rust-lang/crates.io-index)",
"tokio-udp 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)",
"tokio-uds 0.2.5 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "tokio-codec"
version = "0.1.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"bytes 0.4.11 (registry+https://github.com/rust-lang/crates.io-index)",
"futures 0.1.21 (registry+https://github.com/rust-lang/crates.io-index)",
"tokio-io 0.1.11 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "tokio-current-thread"
version = "0.1.4"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"futures 0.1.21 (registry+https://github.com/rust-lang/crates.io-index)",
"tokio-executor 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "tokio-executor"
version = "0.1.6"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"crossbeam-utils 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)",
"futures 0.1.21 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "tokio-fs"
version = "0.1.5"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"futures 0.1.21 (registry+https://github.com/rust-lang/crates.io-index)",
"tokio-io 0.1.11 (registry+https://github.com/rust-lang/crates.io-index)",
"tokio-threadpool 0.1.10 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "tokio-io"
version = "0.1.11"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"bytes 0.4.11 (registry+https://github.com/rust-lang/crates.io-index)",
"futures 0.1.21 (registry+https://github.com/rust-lang/crates.io-index)",
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "tokio-process"
version = "0.2.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"futures 0.1.21 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
"mio 0.6.16 (registry+https://github.com/rust-lang/crates.io-index)",
"mio-named-pipes 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)",
"tokio-io 0.1.11 (registry+https://github.com/rust-lang/crates.io-index)",
"tokio-reactor 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)",
"tokio-signal 0.2.7 (registry+https://github.com/rust-lang/crates.io-index)",
"winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "tokio-reactor"
version = "0.1.8"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"crossbeam-utils 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)",
"futures 0.1.21 (registry+https://github.com/rust-lang/crates.io-index)",
"lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
"mio 0.6.16 (registry+https://github.com/rust-lang/crates.io-index)",
"num_cpus 1.8.0 (registry+https://github.com/rust-lang/crates.io-index)",
"parking_lot 0.7.1 (registry+https://github.com/rust-lang/crates.io-index)",
"slab 0.4.2 (registry+https://github.com/rust-lang/crates.io-index)",
"tokio-executor 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)",
"tokio-io 0.1.11 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "tokio-signal"
version = "0.2.7"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"futures 0.1.21 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
"mio 0.6.16 (registry+https://github.com/rust-lang/crates.io-index)",
"mio-uds 0.6.7 (registry+https://github.com/rust-lang/crates.io-index)",
"signal-hook 0.1.7 (registry+https://github.com/rust-lang/crates.io-index)",
"tokio-executor 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)",
"tokio-io 0.1.11 (registry+https://github.com/rust-lang/crates.io-index)",
"tokio-reactor 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)",
"winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "tokio-tcp"
version = "0.1.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"bytes 0.4.11 (registry+https://github.com/rust-lang/crates.io-index)",
"futures 0.1.21 (registry+https://github.com/rust-lang/crates.io-index)",
"iovec 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)",
"mio 0.6.16 (registry+https://github.com/rust-lang/crates.io-index)",
"tokio-io 0.1.11 (registry+https://github.com/rust-lang/crates.io-index)",
"tokio-reactor 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "tokio-threadpool"
version = "0.1.10"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"crossbeam-channel 0.3.4 (registry+https://github.com/rust-lang/crates.io-index)",
"crossbeam-deque 0.6.3 (registry+https://github.com/rust-lang/crates.io-index)",
"crossbeam-utils 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)",
"futures 0.1.21 (registry+https://github.com/rust-lang/crates.io-index)",
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
"num_cpus 1.8.0 (registry+https://github.com/rust-lang/crates.io-index)",
"rand 0.6.1 (registry+https://github.com/rust-lang/crates.io-index)",
"tokio-executor 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "tokio-timer"
version = "0.2.8"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"crossbeam-utils 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)",
"futures 0.1.21 (registry+https://github.com/rust-lang/crates.io-index)",
"slab 0.4.2 (registry+https://github.com/rust-lang/crates.io-index)",
"tokio-executor 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "tokio-udp"
version = "0.1.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"bytes 0.4.11 (registry+https://github.com/rust-lang/crates.io-index)",
"futures 0.1.21 (registry+https://github.com/rust-lang/crates.io-index)",
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
"mio 0.6.16 (registry+https://github.com/rust-lang/crates.io-index)",
"tokio-codec 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)",
"tokio-io 0.1.11 (registry+https://github.com/rust-lang/crates.io-index)",
"tokio-reactor 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)",
]
[[package]]
name = "tokio-uds"
version = "0.2.5"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"bytes 0.4.11 (registry+https://github.com/rust-lang/crates.io-index)",
"futures 0.1.21 (registry+https://github.com/rust-lang/crates.io-index)",
"iovec 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
"log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
"mio 0.6.16 (registry+https://github.com/rust-lang/crates.io-index)",
"mio-uds 0.6.7 (registry+https://github.com/rust-lang/crates.io-index)",
"tokio-codec 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)",
"tokio-io 0.1.11 (registry+https://github.com/rust-lang/crates.io-index)",
"tokio-reactor 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)",
]
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
[[package]]
name = "toml"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "0.4.10"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update cargo, rls, miri
2018-12-17 19:23:04 +01:00
"serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)",
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
]
Update cargo
2019-03-29 04:13:13 +01:00
[[package]]
name = "toml"
version = "0.5.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)",
]
update mdbook to 0.1.2 and improve printing of errors
2018-01-25 18:32:25 +01:00
[[package]]
name = "toml-query"
version = "0.6.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"error-chain 0.11.0 (registry+https://github.com/rust-lang/crates.io-index)",
"is-match 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update RLS
2018-12-10 08:58:08 +01:00
"lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"regex 0.2.11 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"toml 0.4.10 (registry+https://github.com/rust-lang/crates.io-index)",
update mdbook to 0.1.2 and improve printing of errors
2018-01-25 18:32:25 +01:00
]
Update to newer version of mdbook(2)
2019-01-19 03:39:37 +01:00
[[package]]
name = "toml-query"
version = "0.7.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"error-chain 0.12.0 (registry+https://github.com/rust-lang/crates.io-index)",
"is-match 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
"lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
"regex 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)",
"toml 0.4.10 (registry+https://github.com/rust-lang/crates.io-index)",
]
Update cargo
2018-12-03 02:33:20 +01:00
[[package]]
name = "typenum"
version = "1.10.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
Update to newer version of mdbook(2)
2019-01-19 03:39:37 +01:00
[[package]]
name = "ucd-trie"
version = "0.1.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
Update Cargo submodule Required moving all fulldeps tests depending on `rand` to different locations as now there's multiple `rand` crates that can't be implicitly linked against.
2018-02-26 18:07:16 +01:00
[[package]]
name = "ucd-util"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "0.1.3"
Update Cargo submodule Required moving all fulldeps tests depending on `rand` to different locations as now there's multiple `rand` crates that can't be implicitly linked against.
2018-02-26 18:07:16 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
[[package]]
name = "unicode-bidi"
update crate dependencies I wanted to update mdbook's version. This ended up updating a bunch of other stuff too.
2017-06-27 19:33:32 +02:00
version = "0.3.4"
Update dependencies In order to update mdbook, we have to update other stuff too.
2017-02-20 01:20:57 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"matches 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)",
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
]
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
[[package]]
name = "unicode-normalization"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
version = "0.1.7"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
[[package]]
name = "unicode-segmentation"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
version = "1.2.1"
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
[[package]]
name = "unicode-width"
Bootstrap from 1.28.0-beta.3
2018-06-22 17:48:43 +02:00
version = "0.1.5"
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
[[package]]
name = "unicode-xid"
version = "0.0.4"
source = "registry+https://github.com/rust-lang/crates.io-index"
Update env_logger to 0.5.4 It looks like this cuts down on the number of dependencies in env_logger and notably cuts out a difference between a shared dependency of rls/cargo. My goal here is to ensure that when we compile the RLS/Cargo on CI we only compile Cargo once, and this is one step towards that!
2018-03-01 20:08:48 +01:00
[[package]]
name = "unicode-xid"
version = "0.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
Update Cargo.lock
2019-02-18 10:32:58 +01:00
[[package]]
name = "unicode_categories"
version = "0.1.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
Update dependencies In order to update mdbook, we have to update other stuff too.
2017-02-20 01:20:57 +01:00
[[package]]
name = "unreachable"
Update RLS submodule
2017-06-26 15:43:09 +02:00
version = "1.0.0"
Update dependencies In order to update mdbook, we have to update other stuff too.
2017-02-20 01:20:57 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"void 1.0.2 (registry+https://github.com/rust-lang/crates.io-index)",
]
Autogenerate stubs and the summary of the unstable book
2017-06-12 21:35:47 +02:00
[[package]]
name = "unstable-book-gen"
version = "0.1.0"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"num-traits 0.2.6 (registry+https://github.com/rust-lang/crates.io-index)",
Autogenerate stubs and the summary of the unstable book
2017-06-12 21:35:47 +02:00
"tidy 0.1.0",
]
Update the RLS again
2017-09-25 06:13:29 +02:00
[[package]]
name = "unwind"
version = "0.0.0"
dependencies = [
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"compiler_builtins 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)",
Update the RLS again
2017-09-25 06:13:29 +02:00
"core 0.0.0",
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update the RLS again
2017-09-25 06:13:29 +02:00
]
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
[[package]]
name = "url"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "1.7.2"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule
2018-07-17 18:04:22 +02:00
"idna 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"matches 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)",
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
"percent-encoding 1.0.1 (registry+https://github.com/rust-lang/crates.io-index)",
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
]
[[package]]
name = "url_serde"
version = "0.2.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update cargo, rls, miri
2018-12-17 19:23:04 +01:00
"serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"url 1.7.2 (registry+https://github.com/rust-lang/crates.io-index)",
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
]
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
[[package]]
name = "utf-8"
version = "0.7.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
[[package]]
name = "utf8-ranges"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "1.0.2"
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Update cargo/rls submodules and dependencies Brings in a few regression fixes on the Cargo side, updates the rls to work with the newer Cargo, and also updates other crates.io dependencies to pull in various bug fixes and such.
2017-06-15 04:33:06 +02:00
[[package]]
name = "vcpkg"
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
version = "0.2.6"
Update cargo/rls submodules and dependencies Brings in a few regression fixes on the Cargo side, updates the rls to work with the newer Cargo, and also updates other crates.io dependencies to pull in various bug fixes and such.
2017-06-15 04:33:06 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
[[package]]
name = "vec_map"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
version = "0.8.1"
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
update miri
2018-09-17 09:20:03 +02:00
[[package]]
name = "vergen"
update vergen
2018-12-07 10:12:01 +01:00
version = "3.0.4"
update miri
2018-09-17 09:20:03 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"bitflags 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"chrono 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update cargo
2019-02-03 23:42:29 +01:00
"failure 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)",
update miri
2018-09-17 09:20:03 +02:00
]
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
[[package]]
name = "version_check"
version = "0.1.5"
source = "registry+https://github.com/rust-lang/crates.io-index"
Update dependencies In order to update mdbook, we have to update other stuff too.
2017-02-20 01:20:57 +01:00
[[package]]
name = "void"
version = "1.0.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
Update Cargo's submodule Bring in a few updates and fixes, mostly a standard update.
2018-09-28 20:27:30 +02:00
[[package]]
name = "wait-timeout"
version = "0.1.5"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo's submodule Bring in a few updates and fixes, mostly a standard update.
2018-09-28 20:27:30 +02:00
]
Update Cargo and its dependencies This'll probably have a bunch of build errors, so let's try and head those off and find them sooner rather than later!
2018-01-08 22:56:22 +01:00
[[package]]
name = "walkdir"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
version = "2.2.7"
Update Cargo and its dependencies This'll probably have a bunch of build errors, so let's try and head those off and find them sooner rather than later!
2018-01-08 22:56:22 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"same-file 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"winapi-util 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo and its dependencies This'll probably have a bunch of build errors, so let's try and head those off and find them sooner rather than later!
2018-01-08 22:56:22 +01:00
]
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
[[package]]
name = "winapi"
version = "0.2.8"
source = "registry+https://github.com/rust-lang/crates.io-index"
Update Cargo and its dependencies This'll probably have a bunch of build errors, so let's try and head those off and find them sooner rather than later!
2018-01-08 22:56:22 +01:00
[[package]]
name = "winapi"
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
version = "0.3.6"
Update Cargo and its dependencies This'll probably have a bunch of build errors, so let's try and head those off and find them sooner rather than later!
2018-01-08 22:56:22 +01:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"winapi-i686-pc-windows-gnu 0.4.0 (registry+https://github.com/rust-lang/crates.io-index)",
"winapi-x86_64-pc-windows-gnu 0.4.0 (registry+https://github.com/rust-lang/crates.io-index)",
]
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
[[package]]
name = "winapi-build"
version = "0.1.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
Update Cargo and its dependencies This'll probably have a bunch of build errors, so let's try and head those off and find them sooner rather than later!
2018-01-08 22:56:22 +01:00
[[package]]
name = "winapi-i686-pc-windows-gnu"
version = "0.4.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
[[package]]
name = "winapi-util"
version = "0.1.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
]
Update Cargo and its dependencies This'll probably have a bunch of build errors, so let's try and head those off and find them sooner rather than later!
2018-01-08 22:56:22 +01:00
[[package]]
name = "winapi-x86_64-pc-windows-gnu"
version = "0.4.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
Update the Cargo submodule and rustfix Should hopefully bring in a few more `cargo fix`-related fixes.
2018-07-26 02:25:12 +02:00
[[package]]
name = "wincolor"
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
version = "1.0.1"
Update the Cargo submodule and rustfix Should hopefully bring in a few more `cargo fix`-related fixes.
2018-07-26 02:25:12 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"winapi-util 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)",
Update the Cargo submodule and rustfix Should hopefully bring in a few more `cargo fix`-related fixes.
2018-07-26 02:25:12 +02:00
]
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
[[package]]
name = "ws2_32-sys"
version = "0.2.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"winapi 0.2.8 (registry+https://github.com/rust-lang/crates.io-index)",
"winapi-build 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)",
]
Update to the oxidized rust-installer
2017-05-09 00:01:13 +02:00
[[package]]
name = "xattr"
Update Cargo submodule
2018-07-17 18:04:22 +02:00
version = "0.2.2"
Update to the oxidized rust-installer
2017-05-09 00:01:13 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)",
Update to the oxidized rust-installer
2017-05-09 00:01:13 +02:00
]
[[package]]
name = "xz2"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
version = "0.1.5"
Update to the oxidized rust-installer
2017-05-09 00:01:13 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
Dedupe filetime
2018-07-06 22:52:40 +02:00
"lzma-sys 0.1.10 (registry+https://github.com/rust-lang/crates.io-index)",
Update to the oxidized rust-installer
2017-05-09 00:01:13 +02:00
]
[[package]]
name = "yaml-rust"
version = "0.3.5"
source = "registry+https://github.com/rust-lang/crates.io-index"
Use workspaces and switch to a single Cargo.lock. This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-02 10:55:29 +02:00
[metadata]
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum adler32 1.0.3 (registry+https://github.com/rust-lang/crates.io-index)" = "7e522997b529f05601e05166c07ed17789691f562762c7f3b987263d2dedee5c"
"checksum aho-corasick 0.6.9 (registry+https://github.com/rust-lang/crates.io-index)" = "1e9a933f4e58658d7b12defcf96dc5c720f20832deebe3e0a19efd3b6aaeeb9e"
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
"checksum ammonia 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "fd4c682378117e4186a492b2252b9537990e1617f44aed9788b9a1149de45477"
Update Cargo This notably includes * https://github.com/rust-lang/cargo/pull/5152 * https://github.com/rust-lang/cargo/pull/5188 The first one switches cargo from docopt to clap ( we also update to the latest calp in this repository), the second one should help us to unify feature flags for Cargo itself and RLS, and build Cargo libray only once.
2018-03-16 11:37:14 +01:00
"checksum ansi_term 0.11.0 (registry+https://github.com/rust-lang/crates.io-index)" = "ee49baf6cb617b853aa8d93bf420db2383fab46d314482ca2803b40d5fde979b"
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
"checksum arc-swap 0.3.7 (registry+https://github.com/rust-lang/crates.io-index)" = "1025aeae2b664ca0ea726a89d574fe8f4e77dd712d443236ad1de00379450cf6"
Update Cargo.lock
2019-02-18 10:32:58 +01:00
"checksum argon2rs 0.2.5 (registry+https://github.com/rust-lang/crates.io-index)" = "3f67b0b6a86dae6e67ff4ca2b6201396074996379fba2b92ff649126f37cb392"
Update to newer version of mdbook(2)
2019-01-19 03:39:37 +01:00
"checksum arrayref 0.3.5 (registry+https://github.com/rust-lang/crates.io-index)" = "0d382e583f07208808f6b1249e60848879ba3543f57c32277bf52d69c2f0f0ee"
Update RLS
2018-02-26 04:15:45 +01:00
"checksum arrayvec 0.4.7 (registry+https://github.com/rust-lang/crates.io-index)" = "a1e964f9e24d588183fcb43503abda40d288c8657dfc27311516ce2f05675aef"
revert accidental atty downgrade
2018-07-27 15:10:52 +02:00
"checksum atty 0.2.11 (registry+https://github.com/rust-lang/crates.io-index)" = "9a7d5b8723950951411ee34d271d99dddcc2035a16ab25310ea2c8cfd4369652"
bump backtrace version to get prettier pretty-printing
2018-12-11 22:36:24 +01:00
"checksum backtrace 0.3.11 (registry+https://github.com/rust-lang/crates.io-index)" = "18b65ea1161bfb2dd6da6fade5edd4dbd08fba85012123dd333d2fd1b90b2782"
std: Use backtrace-sys from crates.io This commit switches the standard library to using the `backtrace-sys` crate from crates.io instead of duplicating the logic here in the Rust repositor with the `backtrace-sys`'s crate's logic. Eventually this will hopefully be a good step towards using the `backtrace` crate directly from crates.io itself, but we're not quite there yet! Hopefully this is a small incremental first step we can take.
2018-12-15 01:47:18 +01:00
"checksum backtrace-sys 0.1.27 (registry+https://github.com/rust-lang/crates.io-index)" = "6ea90dd7b012b3d1a2cb6bec16670a0db2c95d4e931e84f4047e0460c1b34c8d"
Update Cargo's submodule Bring in a few updates and fixes, mostly a standard update.
2018-09-28 20:27:30 +02:00
"checksum bit-set 0.5.0 (registry+https://github.com/rust-lang/crates.io-index)" = "6f1efcc46c18245a69c38fcc5cc650f16d3a59d034f3106e9ed63748f695730a"
"checksum bit-vec 0.5.0 (registry+https://github.com/rust-lang/crates.io-index)" = "4440d5cb623bb7390ae27fec0bb6c61111969860f8e3ae198bfa0663645e67cf"
update git2 Fixes build with libressl Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
2017-06-07 21:42:17 +02:00
"checksum bitflags 0.9.1 (registry+https://github.com/rust-lang/crates.io-index)" = "4efd02e230a02e18f92fc2735f44597385ed02ad8f831e7c1c1156ee5e1ab3a5"
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"checksum bitflags 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)" = "228047a76f468627ca71776ecdebd732a3423081fcf5125585bcd7c49886ce12"
Update Cargo.lock
2019-02-18 10:32:58 +01:00
"checksum blake2-rfc 0.2.18 (registry+https://github.com/rust-lang/crates.io-index)" = "5d6d530bdd2d52966a6d03b7a964add7ae1a288d25214066fd4b600f0f796400"
Update to newer version of mdbook(2)
2019-01-19 03:39:37 +01:00
"checksum block-buffer 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)" = "a076c298b9ecdb530ed9d967e74a6027d6a7478924520acddcddc24c1c8ab3ab"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum bufstream 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)" = "40e38929add23cdf8a366df9b0e088953150724bcbe5fc330b0d8eb3b328eec8"
"checksum build_const 0.2.1 (registry+https://github.com/rust-lang/crates.io-index)" = "39092a32794787acd8525ee150305ff051b0aa6cc2abaf193924f5ab05425f39"
Update to newer version of mdbook(2)
2019-01-19 03:39:37 +01:00
"checksum byte-tools 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)" = "560c32574a12a89ecd91f5e742165893f86e3ab98d21f8ea548658eb9eef5f40"
Update Cargo.lock
2019-02-18 10:32:58 +01:00
"checksum bytecount 0.5.1 (registry+https://github.com/rust-lang/crates.io-index)" = "be0fdd54b507df8f22012890aadd099979befdba27713c767993f8380112ca7c"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum byteorder 1.2.7 (registry+https://github.com/rust-lang/crates.io-index)" = "94f88df23a25417badc922ab0f5716cc1330e87f71ddd9203b3a3ccd9cedf75d"
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
"checksum bytes 0.4.11 (registry+https://github.com/rust-lang/crates.io-index)" = "40ade3d27603c2cb345eb0912aec461a6dec7e06a4ae48589904e808335c7afa"
Update Cargo This commit brings in a few Cargo updates * Updates Cargo with experimental HTTP/2 support - a post on the forums will be made about testing this when available. * Bumps Cargo's own version number
2018-09-20 23:37:53 +02:00
"checksum bytesize 1.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "716960a18f978640f25101b5cbf1c6f6b0d3192fab36a2d98ca96f0ecbe41010"
submodules: update clippy from d8b42690 to f5d868c9 Fixes clippy toolstate. Changes: ```` rustup https://github.com/rust-lang/rust/pull/55852/ Fix "too" -> "foo" typo in format.rs Fix `use_self` violation Fix wrong suggestion for `redundant_closure_call` Check for common metadata Fix `use_self` false positive on `use` statements Fix `use_self` false positive Remove `+` from `has_unary_equivalent` Fix dogfood Update println! formatting Fix false positive in check mode caused by `gen_deprecated` RIIR update lints: Add check mode (update_lints.py rewrite complete) changed into_iter to iter and fixed a lint check Fix `collapsible_if` error Fix `possible_missing_comma` false positives format code fix comment spacing change single char str to char add lint to lintarray macro Revert "small fix" small fix added float support for mistyped literal lints tmp progress ````
2018-11-14 14:49:40 +01:00
"checksum cargo_metadata 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)" = "7d8dfe3adeb30f7938e6c1dd5327f29235d8ada3e898aeb08c343005ec2915a2"
submodules: update clippy from f1753522 to 6ce78d12 Changes: ```` wildcard_match_arm: Update lint count. wildcard_match_arm: add nesting issue to known. wildcard_match_arm: lint only enum matches. wildcard_match_arm: update ui test stderr wildcard_match_arm: format test. wilcard_match_arm: run rustfmt. wildcard_match_arm: add lint properly. wildcard_match_arm: rename function. wildcard_match_arm: add simple ui test. wildcard_match_arm: expand lint scope. Change match_wild lint name to WILDCARD_MATCH_ARM. Add match_wild lint (#3649). fetch_prs_between: add .sh file ending cargo fmt Update various docs Use built-in entry_fn detection over self-built cargo fmt Reorganize conditionals: Run faster checks first Maybe fix ICE? Add initial version of const_fn lint Fix `unit_arg` false positive Rustfmt Check hypothetically failing conversion Remove tests for deprecated items Update more changed iterator paths Atomics constants are now handled by the deprecation lint Update changed iterator paths Update const slice processing update test stderr run cargo fmt rustup https://github.com/rust-lang/rust/pull/57907/ Fix documentation for `slow_vector_initialization` rustup https://github.com/rust-lang/rust/pull/57726 Remove unsafe_vector_initialization from added lints Prevent incorrect cast_lossless suggestion in const_fn Incorporate review suggestions Fix dogfood tests on Appveyor test(versioncheck): Use .no_deps() test(versioncheck): Fix version equality check chore(cargo/dependencies/cargo-metadata): Upgrade to 0.7.1 dependencies: update itertools from 0.7 to 0.8 Add script to fetch GitHub PRs between two commits gitattributes: Treat .fixed files as rust files Update changelog with all changes since 0.0.212 Fix `expect_fun_call` lint suggestions ````
2019-01-30 01:24:37 +01:00
"checksum cargo_metadata 0.7.1 (registry+https://github.com/rust-lang/crates.io-index)" = "585784cac9b05c93a53b17a0b24a5cdd1dfdda5256f030e089b549d2390cc720"
Update cc crate to include Armv8-M changes
2019-01-09 15:51:22 +01:00
"checksum cc 1.0.28 (registry+https://github.com/rust-lang/crates.io-index)" = "bb4a8b715cb4597106ea87c7c84b2f1d452c7492033765df7f32651e66fcf749"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum cfg-if 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)" = "082bb9b28e00d3c9d39cc03e64ce4cea0f1bb9b3fde493f0cbc008472d22bdf4"
Handle sub-typing in chalk-engine
2018-11-28 22:11:00 +01:00
"checksum chalk-engine 0.9.0 (registry+https://github.com/rust-lang/crates.io-index)" = "17ec698a6f053a23bfbe646d9f2fde4b02abc19125595270a99e6f44ae0bdd1a"
get `rustc_hash` from external crate
2018-05-24 14:48:02 +02:00
"checksum chalk-macros 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "295635afd6853aa9f20baeb7f0204862440c0fe994c5a253d5f479dac41d047e"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum chrono 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)" = "45912881121cb26fad7c38c17ba7daa18764771836b34fab7d3fbd93ed633878"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"checksum clap 2.32.0 (registry+https://github.com/rust-lang/crates.io-index)" = "b957d88f4b6a63b9d70d5f454ac8011819c6efa7727858f458ab71c756ce2d3e"
Update RLS and rustfmt.
2018-07-26 23:58:55 +02:00
"checksum cloudabi 0.0.3 (registry+https://github.com/rust-lang/crates.io-index)" = "ddfc5b9aa5d4507acaf872de71051dfd0e309860e88966e1051e462a077aac4f"
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"checksum cmake 0.1.33 (registry+https://github.com/rust-lang/crates.io-index)" = "704fbf3bb5149daab0afb255dbea24a1f08d2f4099cedb9baab6d470d4c5eefb"
Update rustfmt and rls
2018-04-26 00:11:28 +02:00
"checksum colored 1.6.0 (registry+https://github.com/rust-lang/crates.io-index)" = "b0aa3473e85a3161b59845d6096b289bb577874cafeaf75ea1b1beaa6572c7fc"
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
"checksum commoncrypto 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)" = "d056a8586ba25a1e4d61cb090900e495952c7886786fc55f909ab2f819b69007"
"checksum commoncrypto-sys 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)" = "1fed34f46747aa73dfaa578069fd8279d2818ade2b55f38f22a9401c7f4083e2"
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"checksum compiler_builtins 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)" = "a28c3898d0c57b26fa6f92de141ba665fa5ac5179f795db06db408be84302395"
Update Clippy
2019-03-03 14:48:03 +01:00
"checksum compiletest_rs 0.3.19 (registry+https://github.com/rust-lang/crates.io-index)" = "56c799b1f7142badf3b047b4c1f2074cc96b6b784fb2432f2ed9c87da0a03749"
Update Cargo.lock
2019-02-18 10:32:58 +01:00
"checksum constant_time_eq 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)" = "8ff012e225ce166d4422e0e78419d901719760f62ae2b7969ca6b564d1b54a9e"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum core-foundation 0.6.3 (registry+https://github.com/rust-lang/crates.io-index)" = "4e2640d6d0bf22e82bed1b73c6aef8d5dd31e5abe6666c57e6d45e2649f4f887"
"checksum core-foundation-sys 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)" = "e7ca8a5221364ef15ce201e8ed2f609fc312682a8f4e0e3d4aa5879764e0fa3b"
"checksum crc 1.8.1 (registry+https://github.com/rust-lang/crates.io-index)" = "d663548de7f5cca343f1e0a48d14dcfb0e9eb4e079ec58883b7251539fa10aeb"
"checksum crc32fast 1.1.2 (registry+https://github.com/rust-lang/crates.io-index)" = "e91d5240c6975ef33aeb5f148f35275c25eda8e8a5f95abe421978b05b8bf192"
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
"checksum crossbeam-channel 0.3.4 (registry+https://github.com/rust-lang/crates.io-index)" = "5b2a9ea8f77c7f9efd317a8a5645f515d903a2d86ee14d2337a5facd1bd52c12"
Update RLS
2018-02-26 04:15:45 +01:00
"checksum crossbeam-deque 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)" = "f739f8c5363aca78cfb059edf753d8f0d36908c348f3d8d1503f03d8b75d9cf3"
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
"checksum crossbeam-deque 0.6.3 (registry+https://github.com/rust-lang/crates.io-index)" = "05e44b8cf3e1a625844d1750e1f7820da46044ff6d28f4d43e455ba3e5bb2c13"
Bump to 1.27.0 Also update some `Cargo.lock` dependencies, finishing up some final steps of our [release process]! This doesn't update the bootstrap compiler just yet but that will come in a follow-up PR. [release process]: https://forge.rust-lang.org/release-process.html
2018-04-02 17:43:55 +02:00
"checksum crossbeam-epoch 0.3.1 (registry+https://github.com/rust-lang/crates.io-index)" = "927121f5407de9956180ff5e936fe3cf4324279280001cd56b669d28ee7e9150"
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
"checksum crossbeam-epoch 0.7.0 (registry+https://github.com/rust-lang/crates.io-index)" = "f10a4f8f409aaac4b16a5474fb233624238fcdeefb9ba50d5ea059aab63ba31c"
Update RLS
2018-02-26 04:15:45 +01:00
"checksum crossbeam-utils 0.2.2 (registry+https://github.com/rust-lang/crates.io-index)" = "2760899e32a1d58d5abb31129f8fae5de75220bc2176e77ff7c627ae45c918d9"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum crossbeam-utils 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)" = "e07fc155212827475223f0bcfae57e945e694fc90950ddf3f6695bbfd5555c72"
Update Cargo submodule Required moving all fulldeps tests depending on `rand` to different locations as now there's multiple `rand` crates that can't be implicitly linked against.
2018-02-26 18:07:16 +01:00
"checksum crypto-hash 0.3.1 (registry+https://github.com/rust-lang/crates.io-index)" = "09de9ee0fc255ace04c7fa0763c9395a945c37c8292bb554f8d48361d1dcf1b4"
Update Cargo submodule Hopefully a relatively routine update!
2018-11-09 21:55:25 +01:00
"checksum curl 0.4.19 (registry+https://github.com/rust-lang/crates.io-index)" = "c7c9d851c825e0c033979d4516c9173bc19a78a96eb4d6ae51d4045440eafa16"
"checksum curl-sys 0.4.15 (registry+https://github.com/rust-lang/crates.io-index)" = "721c204978be2143fab0a84b708c49d79d1f6100b8785610f456043a90708870"
adopt polonius-engine 0.6.2 Also datafrog 2.0.1, which works around a rustdoc bug
2019-01-02 20:45:22 +01:00
"checksum datafrog 2.0.1 (registry+https://github.com/rust-lang/crates.io-index)" = "a0afaad2b26fa326569eb264b1363e8ae3357618c43982b3f285f0774ce76b69"
Reduce the numbers of syn versions compiled from 4 to 2 The last remaining one comes from mdbook. Unfortunately updating it breaks everything
2018-12-08 15:11:47 +01:00
"checksum derive-new 0.5.6 (registry+https://github.com/rust-lang/crates.io-index)" = "6ca414e896ae072546f4d789f452daaecf60ddee4c9df5dc6d5936d769e3d87c"
Update RLS and Rustfmt
2018-11-19 05:21:10 +01:00
"checksum derive_more 0.13.0 (registry+https://github.com/rust-lang/crates.io-index)" = "3f57d78cf3bd45270dad4e70c21ec77a960b36c7a841ff9db76aaa775a8fb871"
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
"checksum diff 0.1.11 (registry+https://github.com/rust-lang/crates.io-index)" = "3c2b69f912779fbb121ceb775d74d51e915af17aaebc38d28a592843a2dd0a3a"
Add tests to rustbuild In order to run tests, previous commits have cfg'd out various parts of rustbuild. Generally speaking, these are filesystem-related operations and process-spawning related parts. Then, rustbuild is run "as normal" and the various steps that where run are retrieved from the cache and checked against the expected results. Note that this means that the current implementation primarily tests "what" we build, but doesn't actually test that what we build *will* build. In other words, it doesn't do any form of dependency verification for any crate. This is possible to implement, but is considered future work. This implementation strives to cfg out as little code as possible; it also does not currently test anywhere near all of rustbuild. The current tests are also not checked for "correctness," rather, they simply represent what we do as of this commit, which may be wrong. Test cases are drawn from the old implementation of rustbuild, though the expected results may vary.
2018-03-10 15:03:06 +01:00
"checksum difference 2.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "524cbf6897b527295dff137cec09ecf3a05f4fddffd7dfcd1585403449e74198"
Update to newer version of mdbook(2)
2019-01-19 03:39:37 +01:00
"checksum digest 0.7.6 (registry+https://github.com/rust-lang/crates.io-index)" = "03b072242a8cbaf9c145665af9d250c59af3b958f83ed6824e13533cf76d5b90"
update miri
2018-11-28 21:22:45 +01:00
"checksum directories 1.0.2 (registry+https://github.com/rust-lang/crates.io-index)" = "72d337a64190607d4fcca2cb78982c5dd57f4916e19696b48a575fa746b6cb0f"
Update Cargo.lock
2019-02-18 10:32:58 +01:00
"checksum dirs 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)" = "88972de891f6118092b643d85a0b28e0678e0f948d7f879aa32f2d5aafe97d2a"
Update dlmalloc to 0.1.3
2019-02-26 01:18:22 +01:00
"checksum dlmalloc 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)" = "f283302e035e61c23f2b86b3093e8c6273a4c3125742d6087e96ade001ca5e63"
Bump to 1.27.0 Also update some `Cargo.lock` dependencies, finishing up some final steps of our [release process]! This doesn't update the bootstrap compiler just yet but that will come in a follow-up PR. [release process]: https://forge.rust-lang.org/release-process.html
2018-04-02 17:43:55 +02:00
"checksum either 1.5.0 (registry+https://github.com/rust-lang/crates.io-index)" = "3be565ca5c557d7f59e7cfcf1844f9e3033650c929c6566f511e8005f205c1d0"
Reduce the numbers of syn versions compiled from 4 to 2 The last remaining one comes from mdbook. Unfortunately updating it breaks everything
2018-12-08 15:11:47 +01:00
"checksum elasticlunr-rs 2.3.4 (registry+https://github.com/rust-lang/crates.io-index)" = "a99a310cd1f9770e7bf8e48810c7bcbb0e078c8fb23a8c7bcf0da4c2bf61a455"
Update to `ena` 0.11.0. This version has some significant speed-ups relating to snapshotting.
2018-11-02 09:46:59 +01:00
"checksum ena 0.11.0 (registry+https://github.com/rust-lang/crates.io-index)" = "f56c93cc076508c549d9bb747f79aa9b4eb098be7b8cad8830c3137ef52d1e00"
Update ena to version 0.13.0
2019-03-25 16:45:44 +01:00
"checksum ena 0.13.0 (registry+https://github.com/rust-lang/crates.io-index)" = "3dc01d68e08ca384955a3aeba9217102ca1aa85b6e168639bf27739f1d749d87"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum env_logger 0.5.13 (registry+https://github.com/rust-lang/crates.io-index)" = "15b0a4d2e39f8420210be8b27eeda28029729e2fd4291019455016c348240c38"
Update Cargo submodule Brings in some fixes and stabilizations!
2018-11-16 12:08:23 +01:00
"checksum env_logger 0.6.0 (registry+https://github.com/rust-lang/crates.io-index)" = "afb070faf94c85d17d50ca44f6ad076bce18ae92f0037d350947240a36e9d42e"
rustbuild: Switch back to using hard links The `copy` function historically in rustbuild used hard links to speed up the copy operations that it does. This logic was backed out, however, in #39518 due to a bug that only showed up on Windows, described in #39504. The cause described in #39504 happened because Cargo, on a fresh build, would overwrite the previous artifacts with new hard links that Cargo itself manages. This behavior in Cargo was fixed in rust-lang/cargo#4390 where it no longer should overwrite files on fresh builds, opportunistically leaving the filesystem intact and not touching it. Hopefully this can help speed up local builds by doing fewer copies all over the place!
2017-09-02 05:46:51 +02:00
"checksum error-chain 0.11.0 (registry+https://github.com/rust-lang/crates.io-index)" = "ff511d5dc435d703f4971bc399647c9bc38e20cb41452e3b9feb4765419ed3f3"
update miri
2018-07-13 10:34:50 +02:00
"checksum error-chain 0.12.0 (registry+https://github.com/rust-lang/crates.io-index)" = "07e791d3be96241c77c43846b665ef1384606da2cd2a48730abe606a12906e02"
Update cargo
2019-02-03 23:42:29 +01:00
"checksum failure 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)" = "795bd83d3abeb9220f257e597aa0080a508b27533824adf336529648f6abf7e2"
"checksum failure_derive 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)" = "ea1063915fd7ef4309e222a5a07cf9c319fb9c7836b1f89b85458672dbb127e1"
Update to newer version of mdbook(2)
2019-01-19 03:39:37 +01:00
"checksum fake-simd 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)" = "e88a8acf291dafb59c2d96e8f59828f3838bb1a70398823ade51a84de6a6deed"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum filetime 0.2.4 (registry+https://github.com/rust-lang/crates.io-index)" = "a2df5c1a8c4be27e7707789dc42ae65976e60b394afd293d1419ab915833e646"
Implement generating graphs of the build steps
2018-03-27 12:44:33 +02:00
"checksum fixedbitset 0.1.9 (registry+https://github.com/rust-lang/crates.io-index)" = "86d4de0081402f5e88cdac65c8dcdcc73118c1a7a465e2a05f0da05843a8ea33"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum flate2 1.0.6 (registry+https://github.com/rust-lang/crates.io-index)" = "2291c165c8e703ee54ef3055ad6188e3d51108e2ded18e9f2476e774fc5ad3d4"
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
"checksum fnv 1.0.6 (registry+https://github.com/rust-lang/crates.io-index)" = "2fad85553e09a6f881f739c29f0b00b0f01357c743266d478b68951ce23285f3"
"checksum foreign-types 0.3.2 (registry+https://github.com/rust-lang/crates.io-index)" = "f6f339eb8adc052cd2ca78910fda869aefa38d22d5cb648e6485e4d3fc06f3b1"
"checksum foreign-types-shared 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)" = "00b0228411908ca8685dba7fc2cdd70ec9990a6e753e89b6ac91a84c40fbaf4b"
Add `std::os::fortanix_sgx` module
2018-12-19 12:56:17 +01:00
"checksum fortanix-sgx-abi 0.3.2 (registry+https://github.com/rust-lang/crates.io-index)" = "3f8cbee5e872cf7db61a999a041f9bc4706ca7bf7df4cb914f53fabb1c1bc550"
Update Cargo and its dependencies This'll probably have a bunch of build errors, so let's try and head those off and find them sooner rather than later!
2018-01-08 22:56:22 +01:00
"checksum fs2 0.4.3 (registry+https://github.com/rust-lang/crates.io-index)" = "9564fc758e15025b46aa6643b1b77d047d1a56a1aea6e01002ac0c7026876213"
Use `jemalloc-sys` on Linux and OSX compilers 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-21 04:15:06 +02:00
"checksum fs_extra 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "5f2a4a2034423744d2cc7ca2068453168dcdb82c438419e639a26bd87839c674"
Update RLS, Rustfmt, Cargo, and Clippy
2018-07-06 02:34:00 +02:00
"checksum fst 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)" = "d94485a00b1827b861dd9d1a2cc9764f9044d4c535514c0760a5a2012ef3399f"
Update Cargo and its dependencies This'll probably have a bunch of build errors, so let's try and head those off and find them sooner rather than later!
2018-01-08 22:56:22 +01:00
"checksum fuchsia-zircon 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)" = "2e9763c69ebaae630ba35f74888db465e49e259ba1bc0eda7d06f4a067615d82"
"checksum fuchsia-zircon-sys 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)" = "3dcaa9ae7725d12cdb85b3ad99a434db70b468c09ded17e012d86b5c1010f7a7"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"checksum futf 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)" = "7c9c1ce3fa9336301af935ab852c437817d14cd33690446569392e65170aac3b"
"checksum futures 0.1.21 (registry+https://github.com/rust-lang/crates.io-index)" = "1a70b146671de62ec8c8ed572219ca5d594d9b06c0b364d5e67b722fc559b48c"
Update cargo
2018-08-14 23:27:26 +02:00
"checksum fwdansi 1.0.1 (registry+https://github.com/rust-lang/crates.io-index)" = "34dd4c507af68d37ffef962063dfa1944ce0dd4d5b82043dbab1dabe088610c3"
Update to newer version of mdbook(2)
2019-01-19 03:39:37 +01:00
"checksum generic-array 0.9.0 (registry+https://github.com/rust-lang/crates.io-index)" = "ef25c5683767570c2bbd7deba372926a55eaae9982d7726ee2a1050239d45b9d"
Bump to 1.27.0 Also update some `Cargo.lock` dependencies, finishing up some final steps of our [release process]! This doesn't update the bootstrap compiler just yet but that will come in a follow-up PR. [release process]: https://forge.rust-lang.org/release-process.html
2018-04-02 17:43:55 +02:00
"checksum getopts 0.2.17 (registry+https://github.com/rust-lang/crates.io-index)" = "b900c08c1939860ce8b54dc6a89e26e00c04c380fd0e09796799bd7f12861e05"
Update Cargo.lock
2019-01-10 13:42:14 +01:00
"checksum git2 0.8.0 (registry+https://github.com/rust-lang/crates.io-index)" = "c7339329bfa14a00223244311560d11f8f489b453fb90092af97f267a6090ab0"
"checksum git2-curl 0.9.0 (registry+https://github.com/rust-lang/crates.io-index)" = "d58551e903ed7e2d6fe3a2f3c7efa3a784ec29b19d0fbb035aaf0497c183fbdd"
Update cargo
2019-03-12 21:34:47 +01:00
"checksum glob 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)" = "9b919933a397b79c37e33b77bb2aa3dc8eb6e165ad809e58ff75bc7db2e34574"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum globset 0.4.2 (registry+https://github.com/rust-lang/crates.io-index)" = "4743617a7464bbda3c8aec8558ff2f9429047e025771037df561d383337ff865"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"checksum handlebars 0.32.4 (registry+https://github.com/rust-lang/crates.io-index)" = "d89ec99d1594f285d4590fc32bac5f75cdab383f1123d504d27862c644a807dd"
Update to newer version of mdbook(2)
2019-01-19 03:39:37 +01:00
"checksum handlebars 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "d82e5750d8027a97b9640e3fefa66bbaf852a35228e1c90790efd13c4b09c166"
Reduce the numbers of syn versions compiled from 4 to 2 The last remaining one comes from mdbook. Unfortunately updating it breaks everything
2018-12-08 15:11:47 +01:00
"checksum heck 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)" = "ea04fa3ead4e05e51a7c806fc07271fdbde4e246a6c6d1efd52e72230b771b82"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"checksum hex 0.3.2 (registry+https://github.com/rust-lang/crates.io-index)" = "805026a5d0141ffc30abb3be3173848ad46a1b1664fe632428479619a3644d77"
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"checksum home 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)" = "80dff82fb58cfbbc617fb9a9184b010be0529201553cda50ad04372bc2333aff"
Reduce the numbers of syn versions compiled from 4 to 2 The last remaining one comes from mdbook. Unfortunately updating it breaks everything
2018-12-08 15:11:47 +01:00
"checksum html5ever 0.22.5 (registry+https://github.com/rust-lang/crates.io-index)" = "c213fa6a618dc1da552f54f85cba74b05d8e883c92ec4e89067736938084c26e"
Update cargo
2019-03-29 04:13:13 +01:00
"checksum http 0.1.16 (registry+https://github.com/rust-lang/crates.io-index)" = "fe67e3678f2827030e89cc4b9e7ecd16d52f132c0b940ab5005f88e821500f6a"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum humantime 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)" = "3ca7e5f2e110db35f93b837c81797f3714500b81d517bf20c431b16d3ca4f114"
Update Cargo submodule
2018-07-17 18:04:22 +02:00
"checksum idna 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)" = "38f09e0f0b1fb55fdee1f17470ad800da77af5186a1a76c026b679358b7e844e"
Update clippy
2018-07-20 09:53:56 +02:00
"checksum if_chain 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)" = "4bac95d9aa0624e7b78187d6fb8ab012b41d9f6f54b1bcb61e61c4845f8357ec"
Update parking_lot to 0.7 Unfortunately this'll dupe parking_lot until the data_structures crate is published and be updated in rls in conjunction with crossbeam-channel
2019-02-22 13:49:19 +01:00
"checksum ignore 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)" = "ad03ca67dc12474ecd91fdb94d758cbd20cb4e7a78ebe831df26a9b7511e1162"
Update Cargo.lock
2019-02-18 10:32:58 +01:00
"checksum im-rc 12.3.0 (registry+https://github.com/rust-lang/crates.io-index)" = "9460397452f537fd51808056ff209f4c4c4c9d20d42ae952f517708726284972"
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
"checksum iovec 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)" = "dbe6e417e7d0975db6512b90796e8ce223145ac4e33c377e4a42882a0e88bb08"
update mdbook to 0.1.2 and improve printing of errors
2018-01-25 18:32:25 +01:00
"checksum is-match 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "7e5b386aef33a1c677be65237cb9d32c3f3ef56bd035949710c4bb13083eb053"
Bump to 1.27.0 Also update some `Cargo.lock` dependencies, finishing up some final steps of our [release process]! This doesn't update the bootstrap compiler just yet but that will come in a follow-up PR. [release process]: https://forge.rust-lang.org/release-process.html
2018-04-02 17:43:55 +02:00
"checksum itertools 0.7.8 (registry+https://github.com/rust-lang/crates.io-index)" = "f58856976b776fedd95533137617a02fb25719f40e7d9b01c7043cd65474f450"
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
"checksum itertools 0.8.0 (registry+https://github.com/rust-lang/crates.io-index)" = "5b8467d9c1cebe26feb08c640139247fac215782d35371ade9a2136ed6085358"
Update Cargo's submodule Bring in a few updates and fixes, mostly a standard update.
2018-09-28 20:27:30 +02:00
"checksum itoa 0.4.3 (registry+https://github.com/rust-lang/crates.io-index)" = "1306f3464951f30e30d12373d31c79fbd52d236e5e896fd92f96ec7babbbe60b"
Update Cargo.lock
2019-03-26 11:29:21 +01:00
"checksum jemalloc-sys 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)" = "7bef0d4ce37578dfd80b466e3d8324bd9de788e249f1accebb0c472ea4b52bdc"
Update cargo
2019-03-29 04:13:13 +01:00
"checksum jobserver 0.1.13 (registry+https://github.com/rust-lang/crates.io-index)" = "b3d51e24009d966c8285d524dbaf6d60926636b2a89caee9ce0bd612494ddc16"
Bump serde_json 1.0.24 -> 1.0.25 This fixes 'cannot find macro `json_internal!` in this scope' RLS compilation error in Rust CI, presumably due to a local macro fix in serde_json 1.0.25 (https://github.com/serde-rs/json/commit/e40cbad70b39a0dd7975be8e5ad9018e2d45f791)
2018-08-25 18:17:55 +02:00
"checksum json 0.11.13 (registry+https://github.com/rust-lang/crates.io-index)" = "9ad0485404155f45cce53a40d4b2d6ac356418300daed05273d9e26f91c390be"
submodule: update rls from c9d25b667a to f331ff7
2019-02-03 01:48:18 +01:00
"checksum jsonrpc-core 10.0.1 (registry+https://github.com/rust-lang/crates.io-index)" = "7a5152c3fda235dfd68341b3edf4121bc4428642c93acbd6de88c26bf95fc5d7"
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
"checksum kernel32-sys 0.2.2 (registry+https://github.com/rust-lang/crates.io-index)" = "7507624b29483431c0ba2d82aece8ca6cdba9382bff4ddd0f7490560c056098d"
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
"checksum lazy_static 0.2.11 (registry+https://github.com/rust-lang/crates.io-index)" = "76f033c7ad61445c5b347c7382dd1237847eb1bce590fe50365dcb33d546be73"
Update RLS
2018-12-10 08:58:08 +01:00
"checksum lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)" = "a374c89b9db55895453a74c1e38861d9deec0b01b405a82516e9d5de4820dea1"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum lazycell 1.2.1 (registry+https://github.com/rust-lang/crates.io-index)" = "b294d6fa9ee409a054354afc4352b0b9ef7ca222c69b8812cbea9e7d2bf3783f"
Add a new wasm32-unknown-wasi target 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. [LINK]: [wasmtime]:
2019-02-13 19:02:22 +01:00
"checksum libc 0.2.51 (registry+https://github.com/rust-lang/crates.io-index)" = "bedcc7a809076656486ffe045abeeac163da1b558e963a31e29fbfbeba916917"
Update cargo, rls, miri
2018-12-17 19:23:04 +01:00
"checksum libgit2-sys 0.7.11 (registry+https://github.com/rust-lang/crates.io-index)" = "48441cb35dc255da8ae72825689a95368bf510659ae1ad55dc4aa88cb1789bf1"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum libnghttp2-sys 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)" = "d75d7966bda4730b722d1eab8e668df445368a24394bae9fc1e8dc0ab3dbe4f4"
Update some `*-sys` dependencies of Cargo/RLS This is intended to help solve #54206 on nightly where the RLS on MinGW is having build issues with accidentally building a `curl` library which links to pthread symbols on Windows (where it should use native mutex locking instead). The build system for these `*-sys` crates have all been rewritten to be based on `cc` to bypass native build systems and platform detection to make sure we configure them correctly.
2018-09-17 18:52:02 +02:00
"checksum libssh2-sys 0.2.11 (registry+https://github.com/rust-lang/crates.io-index)" = "126a1f4078368b163bfdee65fbab072af08a1b374a5551b21e87ade27b1fbf9d"
Directly reference the roadmap upstream
2019-03-04 18:29:23 +01:00
"checksum libtest 0.0.1 (registry+https://github.com/rust-lang/crates.io-index)" = "1a51ac59582b915cdfc426dada72c6d9eba95818a6b481ca340f5c7152166837"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum libz-sys 1.0.25 (registry+https://github.com/rust-lang/crates.io-index)" = "2eb5e43362e38e2bca2fd5f5134c4d4564a23a5c28e9b95411652021a8675ebe"
Breaking change upgrades
2018-08-05 00:24:39 +02:00
"checksum lock_api 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)" = "949826a5ccf18c1b3a7c3d57692778d21768b79e46eb9dd07bfc4c2160036c54"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)" = "c84ec4b527950aa83a329754b01dbe3f58361d1c5efacd1f6d68c494d08a17c6"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"checksum log_settings 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)" = "19af41f0565d7c19b2058153ad0b42d4d5ce89ec4dbf06ed6741114a8b63e7cd"
Update cargo, rls
2019-03-04 22:18:44 +01:00
"checksum lsp-codec 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)" = "169d737ad89cf8ddd82d1804d9122f54568c49377665157277cc90d747b1d31a"
Update Cargo.lock
2019-02-18 10:32:58 +01:00
"checksum lsp-types 0.55.4 (registry+https://github.com/rust-lang/crates.io-index)" = "6392b5843615b8a2adeebe87b83fdd29567c0870baba3407a67e6dbfee4712f8"
Dedupe filetime
2018-07-06 22:52:40 +02:00
"checksum lzma-sys 0.1.10 (registry+https://github.com/rust-lang/crates.io-index)" = "d1eaa027402541975218bb0eec67d6b0412f6233af96e0d096d31dbdfd22e614"
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
"checksum mac 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)" = "c41e0c4fef86961ac6d6f8a82609f55f31b05e4fce149ac5710e439df7619ba4"
Fix links' color
2018-08-15 15:07:07 +02:00
"checksum macro-utils 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)" = "f2c4deaccc2ead6a28c16c0ba82f07d52b6475397415ce40876e559b0b0ea510"
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
"checksum maplit 1.0.1 (registry+https://github.com/rust-lang/crates.io-index)" = "08cbb6b4fef96b6d77bfc40ec491b1690c779e77b05cd9f07f787ed376fd4c43"
"checksum markup5ever 0.7.2 (registry+https://github.com/rust-lang/crates.io-index)" = "bfedc97d5a503e96816d10fedcd5b42f760b2e525ce2f7ec71f6a41780548475"
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"checksum matches 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)" = "7ffc5c5338469d4d3ea17d269fa8ea3512ad247247c30bd2df69e68309ed0a08"
Update MDBook
2018-04-21 23:06:13 +02:00
"checksum mdbook 0.1.7 (registry+https://github.com/rust-lang/crates.io-index)" = "90b5a8d7e341ceee5db3882a06078d42661ddcfa2b3687319cc5da76ec4e782f"
Update to newer version of mdbook(2)
2019-01-19 03:39:37 +01:00
"checksum mdbook 0.2.3 (registry+https://github.com/rust-lang/crates.io-index)" = "0ba0d44cb4089c741b9a91f3e5218298a40699c2f3a070a85014eed290c60819"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum memchr 2.1.1 (registry+https://github.com/rust-lang/crates.io-index)" = "0a3eb002f0535929f1199681417029ebea04aadc0c7a4224b46be99c7f5d6a16"
Always add all modules to the global ThinLTO module analysis when compiling incrementally.
2018-08-31 15:18:08 +02:00
"checksum memmap 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)" = "e2ffa2c986de11a9df78620c01eeaaf27d94d3ff02bf81bfcca953102dd0c6ff"
Update RLS
2018-02-26 04:15:45 +01:00
"checksum memoffset 0.2.1 (registry+https://github.com/rust-lang/crates.io-index)" = "0f9dc261e2b62d7a622bf416ea3c5245cdd5d9a7fcc428c0d06804dfce1775b3"
Update minifier version
2019-01-25 00:07:08 +01:00
"checksum minifier 0.0.28 (registry+https://github.com/rust-lang/crates.io-index)" = "3a2898502751dcc9d66b6fff57f3cf63cc91605e83e1a33515396f5027f8e4ca"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum miniz-sys 0.1.11 (registry+https://github.com/rust-lang/crates.io-index)" = "0300eafb20369952951699b68243ab4334f4b10a88f411c221d444b36c40e649"
"checksum miniz_oxide 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)" = "5ad30a47319c16cde58d0314f5d98202a80c9083b5f61178457403dfb14e509c"
"checksum miniz_oxide_c_api 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)" = "28edaef377517fd9fe3e085c37d892ce7acd1fbeab9239c5a36eec352d8a8b7e"
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
"checksum mio 0.6.16 (registry+https://github.com/rust-lang/crates.io-index)" = "71646331f2619b1026cc302f87a2b8b648d5c6dd6937846a16cc8ce0f347f432"
"checksum mio-named-pipes 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)" = "f5e374eff525ce1c5b7687c4cef63943e7686524a387933ad27ca7ec43779cb3"
"checksum mio-uds 0.6.7 (registry+https://github.com/rust-lang/crates.io-index)" = "966257a94e196b11bb43aca423754d87429960a768de9414f3691d6957abf125"
"checksum miow 0.2.1 (registry+https://github.com/rust-lang/crates.io-index)" = "8c1f2f3b1cf331de6896aabf6e9d55dca90356cc9960cca7eaaf408a355ae919"
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"checksum miow 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)" = "396aa0f2003d7df8395cb93e09871561ccc3e785f0acb369170e8cc74ddf9226"
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
"checksum net2 0.2.33 (registry+https://github.com/rust-lang/crates.io-index)" = "42550d9fb7b6684a6d404d9fa7250c2eb2646df731d1c06afc06dcee9e1bcf88"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"checksum new_debug_unreachable 1.0.1 (registry+https://github.com/rust-lang/crates.io-index)" = "0cdc457076c78ab54d5e0d6fa7c47981757f1e34dc39ff92787f217dede586c4"
Update RLS
2018-02-26 04:15:45 +01:00
"checksum nodrop 0.1.12 (registry+https://github.com/rust-lang/crates.io-index)" = "9a2228dca57108069a5262f2ed8bd2e82496d2e074a06d1ccc7ce1687b6ae0a2"
Reduce the numbers of syn versions compiled from 4 to 2 The last remaining one comes from mdbook. Unfortunately updating it breaks everything
2018-12-08 15:11:47 +01:00
"checksum num-derive 0.2.3 (registry+https://github.com/rust-lang/crates.io-index)" = "8af1847c907c2f04d7bfd572fb25bbb4385c637fe5be163cf2f8c5d778fe1e7d"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"checksum num-integer 0.1.39 (registry+https://github.com/rust-lang/crates.io-index)" = "e83d528d2677f0518c570baf2b7abdcf0cd2d248860b68507bdcb3e91d4c0cea"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum num-traits 0.2.6 (registry+https://github.com/rust-lang/crates.io-index)" = "0b3a5d7cc97d6d30d8b9bc8fa19bf45349ffe46241e8816f50f62f6d6aaabee1"
Update Cargo and its dependencies This'll probably have a bunch of build errors, so let's try and head those off and find them sooner rather than later!
2018-01-08 22:56:22 +01:00
"checksum num_cpus 1.8.0 (registry+https://github.com/rust-lang/crates.io-index)" = "c51a3322e4bca9d212ad9a158a02abc6934d005490c054a2778df73a70aa0a30"
Update some minor dependencies
2017-09-28 00:37:02 +02:00
"checksum open 1.2.1 (registry+https://github.com/rust-lang/crates.io-index)" = "c281318d992e4432cfa799969467003d05921582a7489a8325e37f8a450d5113"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum opener 0.3.2 (registry+https://github.com/rust-lang/crates.io-index)" = "04b1d6b086d9b3009550f9b6f81b10ad9428cf14f404b8e1a3a06f6f012c8ec9"
Upgrade openssl and openssl-sys
2019-01-02 11:06:36 +01:00
"checksum openssl 0.10.16 (registry+https://github.com/rust-lang/crates.io-index)" = "ec7bd7ca4cce6dbdc77e7c1230682740d307d1218a87fb0349a571272be749f9"
Update Cargo and its dependencies Just a routine update!
2017-12-10 18:42:49 +01:00
"checksum openssl-probe 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)" = "77af24da69f9d9341038eba93a073b1fdaaa1b788221b00a69bce9e762cb32de"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum openssl-src 111.1.0+1.1.1a (registry+https://github.com/rust-lang/crates.io-index)" = "26bb632127731bf4ac49bf86a5dde12d2ca0918c2234fc39d79d4da2ccbc6da7"
Upgrade openssl and openssl-sys
2019-01-02 11:06:36 +01:00
"checksum openssl-sys 0.9.40 (registry+https://github.com/rust-lang/crates.io-index)" = "1bb974e77de925ef426b6bc82fce15fd45bdcbeb5728bffcfc7cdeeb7ce1c2d6"
Implement generating graphs of the build steps
2018-03-27 12:44:33 +02:00
"checksum ordermap 0.3.5 (registry+https://github.com/rust-lang/crates.io-index)" = "a86ed3f5f244b372d6b1a00b72ef7f8876d0bc6a78a4c9985c53614041512063"
Update RLS, Rustfmt, Cargo, and Clippy
2018-07-06 02:34:00 +02:00
"checksum ordslice 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)" = "dd20eec3dbe4376829cb7d80ae6ac45e0a766831dca50202ff2d40db46a8a024"
Remove rustc_llvm dependency from rustc_metadata Move the code for loading metadata from rlibs and dylibs from rustc_metadata into rustc_trans, and introduce a trait to avoid introducing a direct dependency on rustc_trans. This means rustc_metadata is no longer rebuilt when LLVM changes.
2017-04-26 23:22:45 +02:00
"checksum owning_ref 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)" = "cdf84f41639e037b484f93433aa3897863b561ed65c6e59c7073d7c561710f37"
Update RLS and Rustfmt Closes #56261
2018-12-01 11:36:32 +01:00
"checksum packed_simd 0.3.1 (registry+https://github.com/rust-lang/crates.io-index)" = "25d36de864f7218ec5633572a800109bbe5a1cc8d9d95a967f3daf93ea7e6ddc"
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
"checksum parking_lot 0.7.1 (registry+https://github.com/rust-lang/crates.io-index)" = "ab41b4aed082705d1056416ae4468b6ea99d52599ecf3169b00088d43113e337"
"checksum parking_lot_core 0.4.0 (registry+https://github.com/rust-lang/crates.io-index)" = "94c8c7923936b28d546dfd14d4472eaf34c99b14e1c973a32b3e6d4eb04298c9"
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
"checksum percent-encoding 1.0.1 (registry+https://github.com/rust-lang/crates.io-index)" = "31010dd2e1ac33d5b46a5b413495239882813e0369f8ed8a5e266f173602f831"
Bump to 1.27.0 Also update some `Cargo.lock` dependencies, finishing up some final steps of our [release process]! This doesn't update the bootstrap compiler just yet but that will come in a follow-up PR. [release process]: https://forge.rust-lang.org/release-process.html
2018-04-02 17:43:55 +02:00
"checksum pest 1.0.6 (registry+https://github.com/rust-lang/crates.io-index)" = "0fce5d8b5cc33983fc74f78ad552b5522ab41442c4ca91606e4236eb4b5ceefc"
Update to newer version of mdbook(2)
2019-01-19 03:39:37 +01:00
"checksum pest 2.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "54f0c72a98d8ab3c99560bfd16df8059cc10e1f9a8e83e6e3b97718dd766e9c3"
Reduce the numbers of syn versions compiled from 4 to 2 The last remaining one comes from mdbook. Unfortunately updating it breaks everything
2018-12-08 15:11:47 +01:00
"checksum pest_derive 1.0.8 (registry+https://github.com/rust-lang/crates.io-index)" = "ca3294f437119209b084c797604295f40227cffa35c57220b1e99a6ff3bf8ee4"
Update to newer version of mdbook(2)
2019-01-19 03:39:37 +01:00
"checksum pest_derive 2.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "833d1ae558dc601e9a60366421196a8d94bc0ac980476d0b67e1d0988d72b2d0"
"checksum pest_generator 2.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "63120576c4efd69615b5537d3d052257328a4ca82876771d6944424ccfd9f646"
"checksum pest_meta 2.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "f5a3492a4ed208ffc247adcdcc7ba2a95be3104f58877d0d02f0df39bf3efb5e"
Update `petgraph` dependency to 0.4.13 This fixes building `bootstrap` using a local Rust nightly.
2018-09-08 08:04:29 +02:00
"checksum petgraph 0.4.13 (registry+https://github.com/rust-lang/crates.io-index)" = "9c3659d1ee90221741f65dd128d9998311b0e40c5d3c23a62445938214abce4f"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"checksum phf 0.7.22 (registry+https://github.com/rust-lang/crates.io-index)" = "7d37a244c75a9748e049225155f56dbcb98fe71b192fd25fd23cb914b5ad62f2"
"checksum phf_codegen 0.7.22 (registry+https://github.com/rust-lang/crates.io-index)" = "4e4048fe7dd7a06b8127ecd6d3803149126e9b33c7558879846da3a63f734f2b"
"checksum phf_generator 0.7.22 (registry+https://github.com/rust-lang/crates.io-index)" = "05a079dd052e7b674d21cb31cbb6c05efd56a2cd2827db7692e2f1a507ebd998"
"checksum phf_shared 0.7.22 (registry+https://github.com/rust-lang/crates.io-index)" = "c2261d544c2bb6aa3b10022b0be371b9c7c64f762ef28c6f5d4f1ef6d97b5930"
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"checksum pkg-config 0.3.14 (registry+https://github.com/rust-lang/crates.io-index)" = "676e8eb2b1b4c9043511a9b7bea0915320d7e502b0a079fb03f9635a5252b18c"
adopt polonius-engine 0.6.2 Also datafrog 2.0.1, which works around a rustdoc bug
2019-01-02 20:45:22 +01:00
"checksum polonius-engine 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)" = "2490c396085801abf88df91758bad806b0890354f0875d624e62ecf0579a8145"
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
"checksum precomputed-hash 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)" = "925383efa346730478fb4838dbe9137d2a47675ad789c546d150a6e1dd4ab31c"
Add tests to rustbuild In order to run tests, previous commits have cfg'd out various parts of rustbuild. Generally speaking, these are filesystem-related operations and process-spawning related parts. Then, rustbuild is run "as normal" and the various steps that where run are retrieved from the cache and checked against the expected results. Note that this means that the current implementation primarily tests "what" we build, but doesn't actually test that what we build *will* build. In other words, it doesn't do any form of dependency verification for any crate. This is possible to implement, but is considered future work. This implementation strives to cfg out as little code as possible; it also does not currently test anywhere near all of rustbuild. The current tests are also not checked for "correctness," rather, they simply represent what we do as of this commit, which may be wrong. Test cases are drawn from the old implementation of rustbuild, though the expected results may vary.
2018-03-10 15:03:06 +01:00
"checksum pretty_assertions 0.5.1 (registry+https://github.com/rust-lang/crates.io-index)" = "3a029430f0d744bc3d15dd474d591bed2402b645d024583082b9f63bb936dac6"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum pretty_env_logger 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)" = "df8b3f4e0475def7d9c2e5de8e5a1306949849761e107b360d03e98eafaffd61"
Update RLS and Rustfmt
2018-11-19 05:21:10 +01:00
"checksum proc-macro2 0.4.24 (registry+https://github.com/rust-lang/crates.io-index)" = "77619697826f31a02ae974457af0b29b723e5619e113e9397b8b82c6bd253f09"
Update cargo
2019-03-29 04:13:13 +01:00
"checksum proptest 0.9.2 (registry+https://github.com/rust-lang/crates.io-index)" = "24f5844db2f839e97e3021980975f6ebf8691d9b9b2ca67ed3feb38dc3edb52c"
bump pulldown
2018-02-18 22:33:56 +01:00
"checksum pulldown-cmark 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)" = "d6fdf85cda6cadfae5428a54661d431330b312bc767ddbc57adbedc24da66e32"
submodules: update clippy from 2f6881c6 to 754b4c07 Changes: ```` rustup https://github.com/rust-lang/rust/pull/54071/ dependencies: update pulldown-cmark from 0.1 to 0.2 s/file_map/source_map ````
2018-11-23 12:52:47 +01:00
"checksum pulldown-cmark 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)" = "eef52fac62d0ea7b9b4dc7da092aa64ea7ec3d90af6679422d3d7e0e14b6ee15"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"checksum quick-error 1.2.2 (registry+https://github.com/rust-lang/crates.io-index)" = "9274b940887ce9addde99c4eee6b5c44cc494b182b97e73dc8ffdcb3397fd3f0"
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
"checksum quine-mc_cluskey 0.2.4 (registry+https://github.com/rust-lang/crates.io-index)" = "07589615d719a60c8dd8a4622e7946465dfef20d1a428f969e3443e7386d5f45"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
"checksum quote 0.3.15 (registry+https://github.com/rust-lang/crates.io-index)" = "7a6e920b65c65f10b2ae65c831a81a073a89edd28c7cce89475bff467ab4167a"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum quote 0.6.10 (registry+https://github.com/rust-lang/crates.io-index)" = "53fa22a1994bd0f9372d7a816207d8a2677ad0325b073f5c5332760f0fb62b5c"
Update Clippy, RLS and Rustfmt
2019-03-18 18:34:18 +01:00
"checksum racer 2.1.21 (registry+https://github.com/rust-lang/crates.io-index)" = "37c88638777cc178684cf648ca0e1dad56646ce105b8593dfe665c436300adc3"
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"checksum rand 0.4.3 (registry+https://github.com/rust-lang/crates.io-index)" = "8356f47b32624fef5b3301c1be97e5944ecdd595409cc5da11d05f211db6cfbd"
Update submodules to include rust-lang-nursery/rust-clippy#3189 and rust-lang-nursery/rls#1054.
2018-09-15 10:40:25 +02:00
"checksum rand 0.5.5 (registry+https://github.com/rust-lang/crates.io-index)" = "e464cd887e869cddcae8792a4ee31d23c7edd516700695608f5b98c67ee0131c"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum rand 0.6.1 (registry+https://github.com/rust-lang/crates.io-index)" = "ae9d223d52ae411a33cf7e54ec6034ec165df296ccd23533d671a28252b6f66a"
"checksum rand_chacha 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "771b009e3a508cb67e8823dda454aaa5368c7bc1c16829fb77d3e980440dd34a"
"checksum rand_core 0.2.2 (registry+https://github.com/rust-lang/crates.io-index)" = "1961a422c4d189dfb50ffa9320bf1f2a9bd54ecb92792fb9477f99a1045f3372"
"checksum rand_core 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)" = "0905b6b7079ec73b314d4c748701f6931eb79fd97c668caa3f1899b22b32c6db"
"checksum rand_hc 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "7b40677c7be09ae76218dc623efbf7b18e34bced3f38883af07bb75630a21bc4"
"checksum rand_isaac 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)" = "ded997c9d5f13925be2a6fd7e66bf1872597f759fd9dd93513dd7e92e5a5ee08"
"checksum rand_pcg 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)" = "086bd09a33c7044e56bb44d5bdde5a60e7f119a9e95b0775f545de759a32fe05"
"checksum rand_xorshift 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "effa3fcaa47e18db002bdde6060944b6d2f9cfd8db471c30e873448ad9187be3"
Bump to 1.27.0 Also update some `Cargo.lock` dependencies, finishing up some final steps of our [release process]! This doesn't update the bootstrap compiler just yet but that will come in a follow-up PR. [release process]: https://forge.rust-lang.org/release-process.html
2018-04-02 17:43:55 +02:00
"checksum rayon 1.0.1 (registry+https://github.com/rust-lang/crates.io-index)" = "80e811e76f1dbf68abf87a759083d34600017fc4e10b6bd5ad84a700f9dba4b1"
Update RLS
2018-02-26 04:15:45 +01:00
"checksum rayon-core 1.4.0 (registry+https://github.com/rust-lang/crates.io-index)" = "9d24ad214285a7729b174ed6d3bcfcb80177807f959d95fafd5bfc5c4f201ac8"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum redox_syscall 0.1.43 (registry+https://github.com/rust-lang/crates.io-index)" = "679da7508e9a6390aeaf7fbd02a800fdc64b73fe2204dd2c8ae66d22d9d5ad5d"
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
"checksum redox_termios 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)" = "7e891cfe48e9100a70a3b6eb652fef28920c117d366339687bd5576160db0f76"
Update Cargo.lock
2019-02-18 10:32:58 +01:00
"checksum redox_users 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)" = "214a97e49be64fd2c86f568dd0cb2c757d2cc53de95b273b6ad0a1c908482f26"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"checksum regex 0.2.11 (registry+https://github.com/rust-lang/crates.io-index)" = "9329abc99e39129fcceabd24cf5d85b4671ef7c29c50e972bc5afe32438ec384"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum regex 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "37e7cbbd370869ce2e8dff25c7018702d10b21a20ef7135316f8daecd6c25b7f"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"checksum regex-syntax 0.5.6 (registry+https://github.com/rust-lang/crates.io-index)" = "7d707a4fa2637f2dca2ef9fd02225ec7661fe01a53623c1e6515b6916511f7a7"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum regex-syntax 0.6.4 (registry+https://github.com/rust-lang/crates.io-index)" = "4e47a2ed29da7a9e1960e1639e7a982e6edc6d49be308a3b02daf511504a16d1"
Update the Cargo submodule
2018-04-18 17:43:59 +02:00
"checksum remove_dir_all 0.5.1 (registry+https://github.com/rust-lang/crates.io-index)" = "3488ba1b9a2084d38645c4c08276a1752dcbf2c7130d74f1569681ad5d2799c5"
Update Cargo.lock
2019-02-18 10:32:58 +01:00
"checksum rls-analysis 0.16.12 (registry+https://github.com/rust-lang/crates.io-index)" = "ae18d8ad01dec3b2014f4d7ae3c607d7adbcff79e5d3b48ea42ea71c10d43a71"
Update RLS and Rustfmt
2018-11-19 05:21:10 +01:00
"checksum rls-blacklist 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)" = "b8ce1fdac03e138c4617ff87b194e1ff57a39bb985a044ccbd8673d30701e411"
Update Cargo.lock
2019-02-18 10:32:58 +01:00
"checksum rls-data 0.18.2 (registry+https://github.com/rust-lang/crates.io-index)" = "5f80b84551b32e26affaf7f12374913b5061730c0dcd185d9e8fa5a15e36e65c"
"checksum rls-span 0.4.1 (registry+https://github.com/rust-lang/crates.io-index)" = "33d66f1d6c6ccd5c98029f162544131698f6ebb61d8c697681cac409dcd08805"
Update RLS and Rustfmt
2018-11-19 05:21:10 +01:00
"checksum rls-vfs 0.7.0 (registry+https://github.com/rust-lang/crates.io-index)" = "72d56425bd5aa86d9d4372b76f0381d3b4bda9c0220e71956c9fcc929f45c1f1"
Update Clippy, RLS and Rustfmt
2019-03-18 18:34:18 +01:00
"checksum rustc-ap-arena 407.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "5aab2fb5e5becf1c9183f6c63b8714817a3e780a20b4fe6b3920751c98a18225"
"checksum rustc-ap-graphviz 407.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "0235ff613d4f96176ea56748010b5d8e978605cc47856ba9bb5372f4f38e9c03"
"checksum rustc-ap-rustc_cratesio_shim 407.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "63e04a90b0dd8597da83633961698c61a2948f50c9d4b9a71e8afafc0ba0f158"
"checksum rustc-ap-rustc_data_structures 407.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "c03988d65fc5130787df32e8ea91738f78a8ed62b7a5bdd77f10e5cceb531d8e"
"checksum rustc-ap-rustc_errors 407.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "8b33b9dc34f9fa50bf7e6fd14f2f3c1adc69833acf43c10f3e9795bd4d613712"
"checksum rustc-ap-rustc_target 407.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "e6de75caef2c7acba11994614266d60238653657677934817ab368d169333cba"
"checksum rustc-ap-serialize 407.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "cf09c60aaee892b0fd107544cfe607d8d463e7f33da34aa823566b8fd2b17f53"
"checksum rustc-ap-syntax 407.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "69f38cc120ff317678bbda8c4f58c1bbc1de64b615383ab01480482dde5e95a1"
"checksum rustc-ap-syntax_pos 407.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "20a0a201141c5c416b1924b079eeefc7b013e34ece0740ce4997f358b3684a7f"
std: Use `rustc_demangle` from crates.io No more need to duplicate the demangling routine between crates.io and the standard library, we can use the exact same one!
2018-12-14 23:37:51 +01:00
"checksum rustc-demangle 0.1.10 (registry+https://github.com/rust-lang/crates.io-index)" = "82ae957aa1b3055d8e086486723c0ccd3d7b8fa190ae8fa2e35543b6171c810e"
Update rustc-hash to hash up to 8 bytes at once with FxHasher
2018-05-24 05:37:40 +02:00
"checksum rustc-hash 1.0.1 (registry+https://github.com/rust-lang/crates.io-index)" = "7540fc8b0c49f096ee9c961cda096467dce8084bec6bdca2fc83895fd9b28cb8"
Update Cargo.lock
2019-02-27 15:17:12 +01:00
"checksum rustc-rayon 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)" = "8d98c51d9cbbe810c8b6693236d3412d8cd60513ff27a3e1b6af483dca0af544"
"checksum rustc-rayon-core 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)" = "526e7b6d2707a5b9bec3927d424ad70fa3cfc68e0ac1b75e46cdbbc95adc5108"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
"checksum rustc-serialize 0.3.24 (registry+https://github.com/rust-lang/crates.io-index)" = "dcf128d1287d2ea9d80910b5f1120d0b8eede3fbf1abe91c40d39ea7d51e6fda"
Directly reference the roadmap upstream
2019-03-04 18:29:23 +01:00
"checksum rustc_term 0.0.1 (registry+https://github.com/rust-lang/crates.io-index)" = "9c69abe7f181d2ea8d2f7b44a4aa86f4b4a567444bcfcf51ed45ede957fbf064"
Update Cargo.lock
2019-01-10 13:42:14 +01:00
"checksum rustc_tools_util 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)" = "b3c5a95edfa0c893236ae4778bb7c4752760e4c0d245e19b5eff33c5aa5eb9dc"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum rustc_version 0.2.3 (registry+https://github.com/rust-lang/crates.io-index)" = "138e3e0acb6c9fb258b19b67cb8abd63c00679d2851805ea151465464fe9030a"
Update cargo, rls, miri
2018-12-17 19:23:04 +01:00
"checksum rustfix 0.4.4 (registry+https://github.com/rust-lang/crates.io-index)" = "af7c21531a91512a4a51b490be6ba1c8eff34fdda0dc5bf87dc28d86748aac56"
Update Cargo's submodule Bring in a few updates and fixes, mostly a standard update.
2018-09-28 20:27:30 +02:00
"checksum rusty-fork 0.2.1 (registry+https://github.com/rust-lang/crates.io-index)" = "9591f190d2852720b679c21f66ad929f9f1d7bb09d1193c26167586029d8489c"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum ryu 0.2.7 (registry+https://github.com/rust-lang/crates.io-index)" = "eb9e9b8cde282a9fe6a42dd4681319bfb63f121b8a8ee9439c6f4107e58a46f7"
"checksum same-file 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)" = "8f20c4be53a8a1ff4c1f1b2bd14570d2f634628709752f0702ecdd2b3f9a5267"
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"checksum schannel 0.1.14 (registry+https://github.com/rust-lang/crates.io-index)" = "0e1a231dc10abf6749cfa5d7767f25888d484201accbd919b66ab5413c502d56"
update Cargo.lock
2019-02-26 11:15:52 +01:00
"checksum scoped-tls 1.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "ea6a9290e3c9cf0f18145ef7ffa62d68ee0bf5fcd651017e586dc7fd5da448c2"
Update Cargo.lock
2019-02-18 10:32:58 +01:00
"checksum scoped_threadpool 0.1.9 (registry+https://github.com/rust-lang/crates.io-index)" = "1d51f5df5af43ab3f1360b429fa5e0152ac5ce8c0bd6485cae490332e96846a8"
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
"checksum scopeguard 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)" = "94258f53601af11e6a49f722422f6e3425c52b06245a5cf9bc09908b174f5e27"
Update Cargo and its dependencies This'll probably have a bunch of build errors, so let's try and head those off and find them sooner rather than later!
2018-01-08 22:56:22 +01:00
"checksum semver 0.9.0 (registry+https://github.com/rust-lang/crates.io-index)" = "1d7eb9ef2c18661902cc47e535f9bc51b78acd254da71d375c2f6720d9a40403"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
"checksum semver-parser 0.7.0 (registry+https://github.com/rust-lang/crates.io-index)" = "388a1df253eca08550bef6c72392cfe7c30914bf41df5269b68cbd6ff8f570a3"
Update cargo, rls, miri
2018-12-17 19:23:04 +01:00
"checksum serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)" = "6fa52f19aee12441d5ad11c9a00459122bd8f98707cadf9778c540674f1935b6"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum serde_derive 1.0.81 (registry+https://github.com/rust-lang/crates.io-index)" = "477b13b646f5b5b56fc95bedfc3b550d12141ce84f466f6c44b9a17589923885"
rustbuild: Switch back to using hard links The `copy` function historically in rustbuild used hard links to speed up the copy operations that it does. This logic was backed out, however, in #39518 due to a bug that only showed up on Windows, described in #39504. The cause described in #39504 happened because Cargo, on a fresh build, would overwrite the previous artifacts with new hard links that Cargo itself manages. This behavior in Cargo was fixed in rust-lang/cargo#4390 where it no longer should overwrite files on fresh builds, opportunistically leaving the filesystem intact and not touching it. Hopefully this can help speed up local builds by doing fewer copies all over the place!
2017-09-02 05:46:51 +02:00
"checksum serde_ignored 0.0.4 (registry+https://github.com/rust-lang/crates.io-index)" = "190e9765dcedb56be63b6e0993a006c7e3b071a016a304736e4a315dc01fb142"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum serde_json 1.0.33 (registry+https://github.com/rust-lang/crates.io-index)" = "c37ccd6be3ed1fdf419ee848f7c758eb31b054d7cd3ae3600e3bae0adf569811"
Update to newer version of mdbook(2)
2019-01-19 03:39:37 +01:00
"checksum sha-1 0.7.0 (registry+https://github.com/rust-lang/crates.io-index)" = "51b9d1f3b5de8a167ab06834a7c883bd197f2191e1dda1a22d9ccfeedbf9aded"
Bump to 1.27.0 Also update some `Cargo.lock` dependencies, finishing up some final steps of our [release process]! This doesn't update the bootstrap compiler just yet but that will come in a follow-up PR. [release process]: https://forge.rust-lang.org/release-process.html
2018-04-02 17:43:55 +02:00
"checksum shell-escape 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)" = "170a13e64f2a51b77a45702ba77287f5c6829375b04a69cf2222acd17d0cfab9"
update mdbook to 0.1.2 and improve printing of errors
2018-01-25 18:32:25 +01:00
"checksum shlex 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)" = "7fdf1b9db47230893d76faad238fd6097fd6d6a9245cd7a4d90dbd639536bbd2"
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
"checksum signal-hook 0.1.7 (registry+https://github.com/rust-lang/crates.io-index)" = "1f272d1b7586bec132ed427f532dd418d8beca1ca7f2caf7df35569b1415a4b4"
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
"checksum siphasher 0.2.2 (registry+https://github.com/rust-lang/crates.io-index)" = "0df90a788073e8d0235a67e50441d47db7c8ad9debd91cbf43736a2a92d36537"
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
"checksum slab 0.4.2 (registry+https://github.com/rust-lang/crates.io-index)" = "c111b5bd5695e56cffe5129854aa230b39c93a305372fdbb2668ca2394eea9f8"
Upgrade `smallvec` to 0.6.7 and use the new `may_dangle` feature.
2018-11-28 22:52:22 +01:00
"checksum smallvec 0.6.7 (registry+https://github.com/rust-lang/crates.io-index)" = "b73ea3738b47563803ef814925e69be00799a8c07420be8b996f8e98fb2336db"
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"checksum socket2 0.3.8 (registry+https://github.com/rust-lang/crates.io-index)" = "c4d11a52082057d87cb5caa31ad812f4504b97ab44732cd8359df2e9ff9f48e7"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"checksum stable_deref_trait 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "ffbc596e092fe5f598b12ef46cc03754085ac2f4d8c739ad61c4ae266cc3b3fa"
"checksum string_cache 0.7.3 (registry+https://github.com/rust-lang/crates.io-index)" = "25d70109977172b127fe834e5449e5ab1740b9ba49fa18a2020f509174f25423"
Update string_cache_codegen to 0.4.2
2019-02-26 12:06:31 +01:00
"checksum string_cache_codegen 0.4.2 (registry+https://github.com/rust-lang/crates.io-index)" = "1eea1eee654ef80933142157fdad9dd8bc43cf7c74e999e369263496f04ff4da"
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
"checksum string_cache_shared 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)" = "b1884d1bc09741d466d9b14e6d37ac89d6909cbcac41dd9ae982d4d063bbedfc"
Update Cargo This notably includes * https://github.com/rust-lang/cargo/pull/5152 * https://github.com/rust-lang/cargo/pull/5188 The first one switches cargo from docopt to clap ( we also update to the latest calp in this repository), the second one should help us to unify feature flags for Cargo itself and RLS, and build Cargo libray only once.
2018-03-16 11:37:14 +01:00
"checksum strsim 0.7.0 (registry+https://github.com/rust-lang/crates.io-index)" = "bb4f380125926a99e52bc279241539c018323fab05ad6368b56f93d9369ff550"
Reduce the numbers of syn versions compiled from 4 to 2 The last remaining one comes from mdbook. Unfortunately updating it breaks everything
2018-12-08 15:11:47 +01:00
"checksum strum 0.11.0 (registry+https://github.com/rust-lang/crates.io-index)" = "f6c3a2071519ab6a48f465808c4c1ffdd00dfc8e93111d02b4fc5abab177676e"
"checksum strum_macros 0.11.0 (registry+https://github.com/rust-lang/crates.io-index)" = "8baacebd7b7c9b864d83a6ba7a246232983e277b86fa5cdec77f565715a4b136"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
"checksum syn 0.11.11 (registry+https://github.com/rust-lang/crates.io-index)" = "d3b891b9015c88c576343b9b3e41c2c11a51c219ef067b264bd9c8aa9b441dad"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum syn 0.15.22 (registry+https://github.com/rust-lang/crates.io-index)" = "ae8b29eb5210bc5cf63ed6149cbf9adfc82ac0be023d8735c176ee74a2db4da7"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
"checksum synom 0.11.3 (registry+https://github.com/rust-lang/crates.io-index)" = "a393066ed9010ebaed60b9eafa373d4b1baac186dd7e008555b0f702b51945b6"
Reduce the numbers of syn versions compiled from 4 to 2 The last remaining one comes from mdbook. Unfortunately updating it breaks everything
2018-12-08 15:11:47 +01:00
"checksum synstructure 0.10.1 (registry+https://github.com/rust-lang/crates.io-index)" = "73687139bf99285483c96ac0add482c3776528beac1d97d444f6e91f203a2015"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum tar 0.4.20 (registry+https://github.com/rust-lang/crates.io-index)" = "a303ba60a099fcd2aaa646b14d2724591a96a75283e4b7ed3d1a1658909d9ae2"
"checksum tempfile 3.0.5 (registry+https://github.com/rust-lang/crates.io-index)" = "7e91405c14320e5c79b3d148e1c86f40749a36e490642202a31689cb1a3452b2"
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
"checksum tendril 0.4.0 (registry+https://github.com/rust-lang/crates.io-index)" = "9de21546595a0873061940d994bbbc5c35f024ae4fd61ec5c5b159115684f508"
Update miri
2019-03-02 20:58:38 +01:00
"checksum term 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)" = "fa63644f74ce96fbeb9b794f66aff2a52d601cbd5e80f4b97123e3899f4570f1"
Update rustfmt to 0.4.1
2018-03-19 15:14:13 +01:00
"checksum term 0.5.1 (registry+https://github.com/rust-lang/crates.io-index)" = "5e6b677dd1e8214ea1ef4297f85dbcbed8e8cdddb561040cc998ca2551c37561"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum termcolor 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)" = "4096add70612622289f2fdcdbd5086dc81c1e2675e6ae58d6c4f62a16c6d7f2f"
Update miri to rustc changes
2017-12-06 09:25:29 +01:00
"checksum termion 1.5.1 (registry+https://github.com/rust-lang/crates.io-index)" = "689a3bdfaab439fd92bc87df5c4c78417d3cbe537487274e9b0b2dce76e92096"
Update miri
2019-03-02 20:58:38 +01:00
"checksum tester 0.5.0 (registry+https://github.com/rust-lang/crates.io-index)" = "5e812cb26c597f86a49b26dbb58b878bd2a2b4b93fc069dc39499228fe556ff6"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"checksum textwrap 0.10.0 (registry+https://github.com/rust-lang/crates.io-index)" = "307686869c93e71f94da64286f9a9524c0f308a9e1c87a583de8e9c9039ad3f6"
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"checksum thread_local 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)" = "c6b53e329000edc2b34dbe8545fd20e55a333362d0a321909685a19bd28c3f1b"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"checksum time 0.1.40 (registry+https://github.com/rust-lang/crates.io-index)" = "d825be0eb33fda1a7e68012d51e9c7f451dc1a69391e7fdc197060bb8c56667b"
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
"checksum tokio 0.1.14 (registry+https://github.com/rust-lang/crates.io-index)" = "4790d0be6f4ba6ae4f48190efa2ed7780c9e3567796abdb285003cf39840d9c5"
"checksum tokio-codec 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)" = "5c501eceaf96f0e1793cf26beb63da3d11c738c4a943fdf3746d81d64684c39f"
"checksum tokio-current-thread 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)" = "331c8acc267855ec06eb0c94618dcbbfea45bed2d20b77252940095273fb58f6"
"checksum tokio-executor 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)" = "30c6dbf2d1ad1de300b393910e8a3aa272b724a400b6531da03eed99e329fbf0"
"checksum tokio-fs 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)" = "0e9cbbc8a3698b7ab652340f46633364f9eaa928ddaaee79d8b8f356dd79a09d"
"checksum tokio-io 0.1.11 (registry+https://github.com/rust-lang/crates.io-index)" = "b53aeb9d3f5ccf2ebb29e19788f96987fa1355f8fe45ea193928eaaaf3ae820f"
"checksum tokio-process 0.2.3 (registry+https://github.com/rust-lang/crates.io-index)" = "88e1281e412013f1ff5787def044a9577a0bed059f451e835f1643201f8b777d"
"checksum tokio-reactor 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)" = "afbcdb0f0d2a1e4c440af82d7bbf0bf91a8a8c0575bcd20c05d15be7e9d3a02f"
"checksum tokio-signal 0.2.7 (registry+https://github.com/rust-lang/crates.io-index)" = "dd6dc5276ea05ce379a16de90083ec80836440d5ef8a6a39545a3207373b8296"
"checksum tokio-tcp 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)" = "1d14b10654be682ac43efee27401d792507e30fd8d26389e1da3b185de2e4119"
"checksum tokio-threadpool 0.1.10 (registry+https://github.com/rust-lang/crates.io-index)" = "17465013014410310f9f61fa10bf4724803c149ea1d51efece131c38efca93aa"
"checksum tokio-timer 0.2.8 (registry+https://github.com/rust-lang/crates.io-index)" = "4f37f0111d76cc5da132fe9bc0590b9b9cfd079bc7e75ac3846278430a299ff8"
"checksum tokio-udp 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)" = "66268575b80f4a4a710ef83d087fdfeeabdce9b74c797535fbac18a2cb906e92"
"checksum tokio-uds 0.2.5 (registry+https://github.com/rust-lang/crates.io-index)" = "037ffc3ba0e12a0ab4aca92e5234e0dedeb48fddf6ccd260f1f150a36a9f2445"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum toml 0.4.10 (registry+https://github.com/rust-lang/crates.io-index)" = "758664fc71a3a69038656bee8b6be6477d2a6c315a6b81f7081f591bffa4111f"
Update cargo
2019-03-29 04:13:13 +01:00
"checksum toml 0.5.0 (registry+https://github.com/rust-lang/crates.io-index)" = "87c5890a989fa47ecdc7bcb4c63a77a82c18f306714104b1decfd722db17b39e"
update mdbook to 0.1.2 and improve printing of errors
2018-01-25 18:32:25 +01:00
"checksum toml-query 0.6.0 (registry+https://github.com/rust-lang/crates.io-index)" = "6854664bfc6df0360c695480836ee90e2d0c965f06db291d10be9344792d43e8"
Update to newer version of mdbook(2)
2019-01-19 03:39:37 +01:00
"checksum toml-query 0.7.0 (registry+https://github.com/rust-lang/crates.io-index)" = "ab234a943a2363ad774020e2f9474a38a85bc4396bace01a96380144aef17db3"
Update cargo
2018-12-03 02:33:20 +01:00
"checksum typenum 1.10.0 (registry+https://github.com/rust-lang/crates.io-index)" = "612d636f949607bdf9b123b4a6f6d966dedf3ff669f7f045890d3a4a73948169"
Update to newer version of mdbook(2)
2019-01-19 03:39:37 +01:00
"checksum ucd-trie 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)" = "71a9c5b1fe77426cf144cc30e49e955270f5086e31a6441dfa8b32efc09b9d77"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum ucd-util 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)" = "535c204ee4d8434478593480b8f86ab45ec9aae0e83c568ca81abf0fd0e88f86"
update crate dependencies I wanted to update mdbook's version. This ended up updating a bunch of other stuff too.
2017-06-27 19:33:32 +02:00
"checksum unicode-bidi 0.3.4 (registry+https://github.com/rust-lang/crates.io-index)" = "49f2bd0c6468a8230e1db229cff8029217cf623c767ea5d60bfbd42729ea54d5"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"checksum unicode-normalization 0.1.7 (registry+https://github.com/rust-lang/crates.io-index)" = "6a0180bc61fc5a987082bfa111f4cc95c4caff7f9799f3e46df09163a937aa25"
"checksum unicode-segmentation 1.2.1 (registry+https://github.com/rust-lang/crates.io-index)" = "aa6024fc12ddfd1c6dbc14a80fa2324d4568849869b779f6bd37e5e4c03344d1"
Bootstrap from 1.28.0-beta.3
2018-06-22 17:48:43 +02:00
"checksum unicode-width 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)" = "882386231c45df4700b275c7ff55b6f3698780a650026380e72dabe76fa46526"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
"checksum unicode-xid 0.0.4 (registry+https://github.com/rust-lang/crates.io-index)" = "8c1f860d7d29cf02cb2f3f359fd35991af3d30bac52c57d265a3c461074cb4dc"
Update env_logger to 0.5.4 It looks like this cuts down on the number of dependencies in env_logger and notably cuts out a difference between a shared dependency of rls/cargo. My goal here is to ensure that when we compile the RLS/Cargo on CI we only compile Cargo once, and this is one step towards that!
2018-03-01 20:08:48 +01:00
"checksum unicode-xid 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "fc72304796d0818e357ead4e000d19c9c174ab23dc11093ac919054d20a6a7fc"
Update Cargo.lock
2019-02-18 10:32:58 +01:00
"checksum unicode_categories 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)" = "39ec24b3121d976906ece63c9daad25b85969647682eee313cb5779fdd69e14e"
Update RLS submodule
2017-06-26 15:43:09 +02:00
"checksum unreachable 1.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "382810877fe448991dfc7f0dd6e3ae5d58088fd0ea5e35189655f84e6814fa56"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum url 1.7.2 (registry+https://github.com/rust-lang/crates.io-index)" = "dd4e7c0d531266369519a4aa4f399d748bd37043b00bde1e4ff1f60a120b355a"
Unify all stage2 tools into a workspace This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m. Notes: when updating Cargo submodule, the replacement version may also need to be updated.
2017-04-30 01:11:58 +02:00
"checksum url_serde 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)" = "74e7d099f1ee52f823d4bdd60c93c3602043c728f5db3b97bdb548467f7bddea"
update mdbook This includes search for all books, a long-requested feature!
2018-04-03 16:32:04 +02:00
"checksum utf-8 0.7.2 (registry+https://github.com/rust-lang/crates.io-index)" = "f1262dfab4c30d5cb7c07026be00ee343a6cf5027fdc0104a9160f354e5db75c"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum utf8-ranges 1.0.2 (registry+https://github.com/rust-lang/crates.io-index)" = "796f7e48bef87609f7ade7e06495a87d5cd06c7866e6a5cbfceffc558a243737"
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"checksum vcpkg 0.2.6 (registry+https://github.com/rust-lang/crates.io-index)" = "def296d3eb3b12371b2c7d0e83bfe1403e4db2d7a0bba324a12b21c4ee13143d"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"checksum vec_map 0.8.1 (registry+https://github.com/rust-lang/crates.io-index)" = "05c78687fb1a80548ae3250346c3db86a80a7cdd77bda190189f2d0a0987c81a"
update vergen
2018-12-07 10:12:01 +01:00
"checksum vergen 3.0.4 (registry+https://github.com/rust-lang/crates.io-index)" = "6aba5e34f93dc7051dfad05b98a18e9156f27e7b431fe1d2398cb6061c0a1dba"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum version_check 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)" = "914b1a6776c4c929a602fafd8bc742e06365d4bcbe48c30f9cca5824f70dc9dd"
Update dependencies In order to update mdbook, we have to update other stuff too.
2017-02-20 01:20:57 +01:00
"checksum void 1.0.2 (registry+https://github.com/rust-lang/crates.io-index)" = "6a02e4885ed3bc0f2de90ea6dd45ebcbb66dacffe03547fadbb0eeae2770887d"
Update Cargo's submodule Bring in a few updates and fixes, mostly a standard update.
2018-09-28 20:27:30 +02:00
"checksum wait-timeout 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)" = "b9f3bf741a801531993db6478b95682117471f76916f5e690dd8d45395b09349"
Update Cargo submodule and its dependencies Hopefully just another routine update! So far this starts to enable the `std::arch` in stage0 builds of rustc. This means that we may need stage0/not(stage0) in stdsimd itself, but more and more code is starting to use `std::arch` so I think it's time to start shifting the balance of work here.
2018-12-08 12:06:54 +01:00
"checksum walkdir 2.2.7 (registry+https://github.com/rust-lang/crates.io-index)" = "9d9d7ed3431229a144296213105a390676cc49c9b6a72bd19f3176c98e129fa1"
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
"checksum winapi 0.2.8 (registry+https://github.com/rust-lang/crates.io-index)" = "167dc9d6949a9b857f3451275e911c3f44255842c1f7a76f33c55103a909087a"
Update Cargo, build curl/OpenSSL statically via features 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-10-08 19:39:09 +02:00
"checksum winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)" = "92c1eb33641e276cfa214a0522acad57be5c56b10cb348b3c5117db75f3ac4b0"
Re-implement rustbook in terms of mdbook mdbook has a lot of optional dependencies that we don't want, so instead of using it directly, we re-build rustbook to use mdbook as a library. For convenience' sake, we keep the same CLI interface as mdbook; the only difference is that it only accepts build and test subcommands, rather than the full range.
2017-02-08 00:13:57 +01:00
"checksum winapi-build 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)" = "2d315eee3b34aca4797b2da6b13ed88266e6d612562a0c46390af8299fc699bc"
Update Cargo and its dependencies This'll probably have a bunch of build errors, so let's try and head those off and find them sooner rather than later!
2018-01-08 22:56:22 +01:00
"checksum winapi-i686-pc-windows-gnu 0.4.0 (registry+https://github.com/rust-lang/crates.io-index)" = "ac3b87c63620426dd9b991e5ce0329eff545bccbbb34f3be09ff6fb6ab51b7b6"
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"checksum winapi-util 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)" = "afc5508759c5bf4285e61feb862b6083c8480aec864fa17a81fdec6f69b461ab"
Update Cargo and its dependencies This'll probably have a bunch of build errors, so let's try and head those off and find them sooner rather than later!
2018-01-08 22:56:22 +01:00
"checksum winapi-x86_64-pc-windows-gnu 0.4.0 (registry+https://github.com/rust-lang/crates.io-index)" = "712e227841d057c1ee1cd2fb22fa7e5a5461ae8e48fa2ca79ec42cfc1931183f"
Update Cargo submodule Also update Cargo's dependencies while we're at it
2018-08-21 19:23:47 +02:00
"checksum wincolor 1.0.1 (registry+https://github.com/rust-lang/crates.io-index)" = "561ed901ae465d6185fa7864d63fbd5720d0ef718366c9a4dc83cf6170d7e9ba"
submodules: update rls from ae0d89a to c9d25b6 Changes: ```` Remove state.analysis due to Rust PR #57476 Improve missing nightly readme info Bump languageserver-types to v0.54.0 and renam crate name to lsp-types Delete bors.toml Fix tests Fix https://github.com/rust-lang/rls/issues/1231 Implement asynchronous message reading Use typed requests Implement Tokio-based test LSP client Update README.md to account for Travis url change Simplify wait_for_all recv calls Update dependencies Revert NLL bug workaround Remove old test_data entry in .gitignore Reorganize some tests Don't test RLS binary target directly Move tooltip tests to integration tests Simplify tooltip test harness Only use FIXTURES_DIR to determine fixtures Remove src/test/mod.rs Centralise FIXTURES_DIR across unit and integration tests Move lens test to tests/ Suppress unused warnings in tests/* Beautify main.rs and lib.rs WIP: Move tests Move src/test/harness to tests/support/harness Split RLS into bin/lib Update Clippy Change all mentions of `rls-preview` to `rls` Make config mutex borrow scope explicit Fallback to racer definition ```` Fixes rls build.
2019-01-21 16:32:43 +01:00
"checksum ws2_32-sys 0.2.1 (registry+https://github.com/rust-lang/crates.io-index)" = "d59cefebd0c892fa2dd6de581e937301d8552cb44489cdff035c6187cb63fa5e"
Update Cargo submodule
2018-07-17 18:04:22 +02:00
"checksum xattr 0.2.2 (registry+https://github.com/rust-lang/crates.io-index)" = "244c3741f4240ef46274860397c7c74e50eb23624996930e484c16679633a54c"
Update Cargo.lock dependencies Run `cargo update` and let's see how far we can get!
2018-07-02 18:33:16 +02:00
"checksum xz2 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)" = "df8bf41d3030c3577c9458fd6640a05afbf43b150d0b531b16bd77d3f794f27a"
Directly reference the roadmap upstream
2019-03-04 18:29:23 +01:00
"checksum yaml-rust 0.3.5 (registry+https://github.com/rust-lang/crates.io-index)" = "e66366e18dc58b46801afbf2ca7661a9f59cc8c5962c29892b6039b4f86fa992"
Reference in New Issue Copy Permalink