about summary refs log tree commit diff
path: root/src/libstd/Cargo.toml
AgeCommit message (Collapse)AuthorLines
2020-05-17use new interface to initialize CondvarStefan Lankes-1/+1
HermitCore introduce a new interface to intialize conditional variables. Consequently, minor changes are required to support this interface.
2020-04-26use new interface to create threads on HermitCoreStefan Lankes-1/+1
- the new interface allows to define the stack size
2020-04-11Make panic-unwind a default feature for libstdLuca Barbieri-1/+1
x.py sets it unconditionally, so want it for plain "cargo build". We need to load one of the panic runtimes that is in src (vs. pre-built in the compiler's sysroot) to ensure that we don't load libpanic_unwind from the sysroot. That would lead to a load of libcore, also from the sysroot, and create lots of errors about duplicate lang items.
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.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-26 04:02:49 +0000