about summary refs log tree commit diff
path: root/src/libstd/Cargo.toml
AgeCommit message (Collapse)AuthorLines
2020-03-30move the definition of thread priorities to hermit-abiStefan Lankes-1/+1
2020-03-30move OS constants to platform crateStefan Lankes-1/+1
2020-03-24Update backtrace crate to 0.3.46Tomasz Miąsko-1/+1
2020-02-10Bump version to backtrace without the headerJane Lusby-1/+1
2020-01-09Remove sanitizer runtime cratesTomasz Miąsko-10/+0
2019-12-03Update the `wasi` crate for `wasm32-wasi`Alex Crichton-1/+1
This commit updates the `wasi` crate used by the standard library which is used to implement most of the functionality of libstd on the `wasm32-wasi` target. This update comes with a brand new crate structure in the `wasi` crate which caused quite a few changes for the wasi target here, but it also comes with a significant change to where the functionality is coming from. The WASI specification is organized into "snapshots" and a new snapshot happened recently, so the WASI APIs themselves have changed since the previous revision. This had only minor impact on the public facing surface area of libstd, only changing on `u32` to a `u64` in an unstable API. The actual source for all of these types and such, however, is now coming from the `wasi_preview_snapshot1` module instead of the `wasi_unstable` module like before. This means that any implementors generating binaries will need to ensure that their embedding environment handles the `wasi_preview_snapshot1` module.
2019-10-25Merge branch 'master' into rusty-hermit, resolve conflictsStefan Lankes-1/+1
2019-10-24Update hashbrown to 0.6.2Alex Crichton-1/+1
Pulls in rust-lang/hashbrown#119 which should be a good improvement for compile times of hashmap-heavy crates.
2019-10-21add aarch64 support for HermitCoreStefan Lankes-1/+1
2019-10-20Merge branch 'master' into rusty-hermitStefan Lankes-1/+1
2019-10-20move interface to the unikernel in the crate hermit-abiStefan Lankes-0/+3
=> simplifies the maintenance of the interface
2019-10-09Implement (HashMap) Entry::insert as per #60142Félix Saparelli-1/+1
2019-09-23Remove unused dependenciesShotaro Yamada-3/+0
2019-09-14rename the crate, not the featureRalf Jung-6/+7
2019-09-14std: always depend on backtrace, but only enable its features on demandRalf Jung-9/+9
2019-09-09Rollup merge of #63806 - mati865:rand, r=alexcrichtonMazdak Farrokhzad-1/+1
Upgrade rand to 0.7 Also upgrades `getrandom` to avoid bug encountered by https://github.com/rust-lang/rust/pull/61393 which bumps libc to `0.2.62`.
2019-09-08Rollup merge of #64152 - cramertj:update-backtrace, r=alexcrichtonMazdak Farrokhzad-1/+1
Use backtrace formatting from the backtrace crate r? @alexcrichton
2019-09-06Upgrade rand to 0.7Mateusz Mikuła-1/+1
2019-09-06Rollup merge of #63676 - newpavlov:wasi, r=alexcrichtonMazdak Farrokhzad-0/+3
Use wasi crate for Core API Blocked by: CraneStation/rust-wasi#5 Blocks: rust-lang/libc#1461 cc @sunfishcode @alexcrichton
2019-09-04Use backtrace formatting from the backtrace crateTaylor Cramer-1/+1
2019-09-03make wasi a target-specific dependencyArtyom Pavlov-1/+3
2019-08-29update to wasi v0.7newpavlov-1/+1
2019-08-28std: Remove the `wasm_syscall` featureAlex Crichton-5/+0
This commit removes the `wasm_syscall` feature from the wasm32-unknown-unknown build of the standard library. This feature was originally intended to allow an opt-in way to interact with the operating system in a posix-like way but it was never stabilized. Nowadays with the advent of the `wasm32-wasi` target that should entirely replace the intentions of the `wasm_syscall` feature.
2019-08-21move cvtnewpavlov-0/+1
2019-08-19std: Update `backtrace` crate dependencyAlex Crichton-1/+1
This commit updates the `backtrace` crate from 0.3.34 to 0.3.35. The [included set of changes][changes] for this update mostly includes some gimli-related improvements (not relevant for the standard library) but critically includes a fix for rust-lang/backtrace-rs#230. The standard library will not aqcuire a session-local lock whenever a backtrace is generated on Windows to allow external synchronization with the `backtrace` crate itself, allowing `backtrace` to be safely used while other threads may be panicking. [changes]: https://github.com/rust-lang/backtrace-rs/compare/0.3.34...0.3.35
2019-08-16Update hashbrown to 0.5.0Simon Sapin-1/+1
2019-07-31Attempt to fix backtrace tests on i686-msvcAlex Crichton-1/+1
Some fixes for i686-msvc and Windows have landed on the `backtrace` crate but hadn't made their way here yet. Let's update that and see if it passes CI.
2019-07-25std: Use native `#[thread_local]` TLS on wasmAlex Crichton-5/+0
This commit moves `thread_local!` on WebAssembly targets to using the `#[thread_local]` attribute in LLVM. This was recently implemented upstream and is [in the process of being documented][dox]. This change only takes affect if modules are compiled with `+atomics` which is currently unstable and a pretty esoteric method of compiling wasm artifacts. This "new power" of the wasm toolchain means that the old `wasm-bindgen-threads` feature of the standard library can be removed since it should now be possible to create a fully functioning threaded wasm module without intrusively dealing with libstd symbols or intrinsics. Yay! [dox]: https://github.com/WebAssembly/tool-conventions/pull/116
2019-07-15Update the stdarch submodulegnzlbg-2/+2
2019-06-14make sure we use cfg-if as a std dependencyRalf Jung-1/+1
2019-06-10std: Remove internal definitions of `cfg_if!` macroAlex Crichton-0/+1
This is duplicated in a few locations throughout the sysroot to work around issues with not exporting a macro in libstd but still wanting it available to sysroot crates to define blocks. Nowadays though we can simply depend on the `cfg-if` crate on crates.io, allowing us to use it from there!
2019-06-07Rollup merge of #61603 - Goirad:increase-sgx-heapsize, r=alexcrichtonMazdak Farrokhzad-0/+2
Increases heap size available during testing for SGX PR [61540](https://github.com/rust-lang/rust/pull/61540) causes at least one test to fail when run for the SGX platform due to lack of memory. This PR increases the heapsize available during tests, which is a good thing regardless of the status of that PR.
2019-06-06increase max heapsize available during sgx testsDario Gonzalez-0/+2
2019-06-06Update compiler_builtinsvarkor-1/+1
2019-06-04std: Update dependency on `backtrace`Alex Crichton-1/+1
Discovered in #61416 an accidental regression in libstd's backtrace behavior is that it previously attempted to consult libbacktrace and would then fall back to `dladdr` if libbacktrace didn't report anything. The `backtrace` crate, however, did not do this, so that's now been fixed! Changes: https://github.com/rust-lang/backtrace-rs/compare/0.3.25...0.3.27 Closes #61416
2019-06-01Bump hashbrown to 0.4.0Amanieu d'Antras-1/+1
Fixes #61357
2019-05-25std: Depend on `backtrace` crate from crates.ioAlex Crichton-3/+12
This commit removes all in-tree support for generating backtraces in favor of depending on the `backtrace` crate on crates.io. This resolves a very longstanding piece of duplication where the standard library has long contained the ability to generate a backtrace on panics, but the code was later extracted and duplicated on crates.io with the `backtrace` crate. Since that fork each implementation has seen various improvements one way or another, but typically `backtrace`-the-crate has lagged behind libstd in one way or another. The goal here is to remove this duplication of a fairly critical piece of code and ensure that there's only one source of truth for generating backtraces between the standard library and the crate on crates.io. Recently I've been working to bring the `backtrace` crate on crates.io up to speed with the support in the standard library which includes: * Support for `StackWalkEx` on MSVC to recover inline frames with debuginfo. * Using `libbacktrace` by default on MinGW targets. * Supporting `libbacktrace` on OSX as an option. * Ensuring all the requisite support in `backtrace`-the-crate compiles with `#![no_std]`. * Updating the `libbacktrace` implementation in `backtrace`-the-crate to initialize the global state with the correct filename where necessary. After reviewing the code in libstd the `backtrace` crate should be at exact feature parity with libstd today. The backtraces generated should have the same symbols and same number of frames in general, and there's not known divergence from libstd currently. Note that one major difference between libstd's backtrace support and the `backtrace` crate is that on OSX the crates.io crate enables the `coresymbolication` feature by default. This feature, however, uses private internal APIs that aren't published for OSX. While they provide more accurate backtraces this isn't appropriate for libstd distributed as a binary, so libstd's dependency on the `backtrace` crate explicitly disables this feature and forces OSX to use `libbacktrace` as a symbolication strategy. The long-term goal of this refactoring is to eventually move us towards a world where we can drop `libbacktrace` entirely and simply use Gimli and the surrounding crates for backtrace support. That's still aways off but hopefully will much more easily enabled by having the source of truth for backtraces live in crates.io! Procedurally if we go forward with this I'd like to transfer the `backtrace-rs` crate to the rust-lang GitHub organization as well, but I figured I'd hold off on that until we get closer to merging.
2019-05-22Bump compiler-builtins to 0.1.15Alex Crichton-3/+3
This commit bumps the `compiler-builtins` dependency to 0.1.15 which expects to have the source for `compiler-rt` provided externally if the `c` feature is enabled. This then plumbs through the necessary support in the build system to ensure that if the `llvm-project` directory is checked out and present that we enable the `c` feature of `compiler-builtins` and compile in all the C intrinsics.
2019-05-17Update the compiler_builtins crateAlex Crichton-2/+2
This updates to 0.1.13 for `compiler_builtins`, published to fix a few issues. The feature changes here are updated because `compiler_builtins` no longer enables the `c` feature by default but we want to do so through our build still. Closes #60747 Closes #60782
2019-05-09Switch to SPDX 2.1 license expressionDavid Tolnay-1/+1
According to the Cargo Reference: https://doc.rust-lang.org/cargo/reference/manifest.html > This is an SPDX 2.1 license expression for this package. Currently > crates.io will validate the license provided against a whitelist of > known license and exception identifiers from the SPDX license list > 2.4. Parentheses are not currently supported. > > Multiple licenses can be separated with a `/`, although that usage > is deprecated. Instead, use a license expression with AND and OR > operators to get more explicit semantics.
2019-05-08std: Update compiler-builtins crateAlex Crichton-1/+1
Pulls in a fix for ensuring that wasm targets have code in compiler-builtins for `ldexp` which LLVM can generate references to.
2019-04-24Update hashbrown to 0.3.0Amanieu d'Antras-1/+1
2019-04-24Update hashbrown to 0.2.2Amanieu d'Antras-1/+1
2019-04-24Update hashbrown to 0.2.1Amanieu d'Antras-1/+1
2019-04-24Make libstd depend on the hashbrown crateAmanieu d'Antras-0/+1
2019-04-04std: Upgrade `compiler_builtins` to fix wasi linkageAlex Crichton-1/+1
Turns out we needed to exclude a number of math functions on the `wasm32-unknown-wasi` target, and this was fixed in 0.1.9 of compiler-builtins and this is pulling in the fix to libstd's own build.
2019-04-03Support using LLVM's libunwind as the unwinder implementationPetr Hosek-0/+1
This avoids the dependency on host libraries such as libgcc_s which may be undesirable in some deployment environments where these aren't available.
2019-03-29Add a new wasm32-unknown-wasi targetAlex Crichton-2/+2
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-03-25SGX target: fix std unit testsJethro Beekman-0/+4
2019-02-28libstd => 2018Taiki Endo-0/+1
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-25 16:41:05 +0000