2016-01-22 00:19:23 +01:00
|
|
|
[package]
|
|
|
|
|
authors = ["The Rust Project Developers"]
|
|
|
|
|
name = "std"
|
|
|
|
|
version = "0.0.0"
|
|
|
|
|
build = "build.rs"
|
2017-10-31 20:49:29 +01:00
|
|
|
license = "MIT/Apache-2.0"
|
2017-10-31 20:57:27 +01:00
|
|
|
repository = "https://github.com/rust-lang/rust.git"
|
2017-10-31 21:10:10 +01:00
|
|
|
description = "The Rust Standard Library"
|
2016-01-22 00:19:23 +01:00
|
|
|
|
|
|
|
|
[lib]
|
|
|
|
|
name = "std"
|
|
|
|
|
path = "lib.rs"
|
|
|
|
|
crate-type = ["dylib", "rlib"]
|
|
|
|
|
|
|
|
|
|
[dependencies]
|
|
|
|
|
alloc = { path = "../liballoc" }
|
|
|
|
|
alloc_system = { path = "../liballoc_system" }
|
2016-11-24 03:49:54 +01:00
|
|
|
panic_unwind = { path = "../libpanic_unwind", optional = true }
|
rustc: Implement custom panic runtimes
This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.
[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md
Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.
With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.
Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).
2016-04-09 01:18:40 +02:00
|
|
|
panic_abort = { path = "../libpanic_abort" }
|
2016-01-22 00:19:23 +01:00
|
|
|
core = { path = "../libcore" }
|
|
|
|
|
libc = { path = "../rustc/libc_shim" }
|
2017-06-22 22:14:00 +02:00
|
|
|
compiler_builtins = { path = "../rustc/compiler_builtins_shim" }
|
2017-02-13 10:57:50 +01:00
|
|
|
profiler_builtins = { path = "../libprofiler_builtins", optional = true }
|
rustc: Implement custom panic runtimes
This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.
[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md
Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.
With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.
Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).
2016-04-09 01:18:40 +02:00
|
|
|
unwind = { path = "../libunwind" }
|
2016-01-22 00:19:23 +01:00
|
|
|
|
2017-11-01 20:32:13 +01:00
|
|
|
[dev-dependencies]
|
2018-08-05 00:24:39 +02:00
|
|
|
rand = "0.5"
|
2017-11-01 20:32:13 +01:00
|
|
|
|
2017-04-17 22:22:16 +02:00
|
|
|
[target.x86_64-apple-darwin.dependencies]
|
|
|
|
|
rustc_asan = { path = "../librustc_asan" }
|
|
|
|
|
rustc_tsan = { path = "../librustc_tsan" }
|
|
|
|
|
|
2016-12-30 05:28:11 +01:00
|
|
|
[target.x86_64-unknown-linux-gnu.dependencies]
|
2017-02-15 23:00:41 +01:00
|
|
|
rustc_asan = { path = "../librustc_asan" }
|
|
|
|
|
rustc_lsan = { path = "../librustc_lsan" }
|
|
|
|
|
rustc_msan = { path = "../librustc_msan" }
|
|
|
|
|
rustc_tsan = { path = "../librustc_tsan" }
|
2016-12-30 05:28:11 +01:00
|
|
|
|
2016-01-22 00:19:23 +01:00
|
|
|
[build-dependencies]
|
2018-05-23 04:40:02 +02:00
|
|
|
cc = "1.0"
|
2016-01-22 00:19:23 +01:00
|
|
|
build_helper = { path = "../build_helper" }
|
|
|
|
|
|
|
|
|
|
[features]
|
2016-07-26 22:21:25 +02:00
|
|
|
backtrace = []
|
2016-11-24 03:49:54 +01:00
|
|
|
panic-unwind = ["panic_unwind"]
|
2017-02-13 10:57:50 +01:00
|
|
|
profiler = ["profiler_builtins"]
|
std: Implement TLS for wasm32-unknown-unknown
This adds an implementation of thread local storage for the
`wasm32-unknown-unknown` target when the `atomics` feature is
implemented. This, however, comes with a notable caveat of that it
requires a new feature of the standard library, `wasm-bindgen-threads`,
to be enabled.
Thread local storage for wasm (when `atomics` are enabled and there's
actually more than one thread) is powered by the assumption that an
external entity can fill in some information for us. It's not currently
clear who will fill in this information nor whose responsibility it
should be long-term. In the meantime there's a strategy being gamed out
in the `wasm-bindgen` project specifically, and the hope is that we can
continue to test and iterate on the standard library without committing
to a particular strategy yet.
As to the details of `wasm-bindgen`'s strategy, LLVM doesn't currently
have the ability to emit custom `global` values (thread locals in a
`WebAssembly.Module`) so we leverage the `wasm-bindgen` CLI tool to do
it for us. To that end we have a few intrinsics, assuming two global values:
* `__wbindgen_current_id` - gets the current thread id as a 32-bit
integer. It's `wasm-bindgen`'s responsibility to initialize this
per-thread and then inform libstd of the id. Currently `wasm-bindgen`
performs this initialization as part of the `start` function.
* `__wbindgen_tcb_{get,set}` - in addition to a thread id it's assumed
that there's a global available for simply storing a pointer's worth
of information (a thread control block, which currently only contains
thread local storage). This would ideally be a native `global`
injected by LLVM, but we don't have a great way to support that right
now.
To reiterate, this is all intended to be unstable and purely intended
for testing out Rust on the web with threads. The story is very likely
to change in the future and we want to make sure that we're able to do
that!
2018-10-10 08:10:25 +02:00
|
|
|
|
|
|
|
|
# An off-by-default feature which enables a linux-syscall-like ABI for libstd to
|
|
|
|
|
# interoperate with the host environment. Currently not well documented and
|
|
|
|
|
# requires rebuilding the standard library to use it.
|
2017-12-31 17:40:34 +01:00
|
|
|
wasm_syscall = []
|
std: Implement TLS for wasm32-unknown-unknown
This adds an implementation of thread local storage for the
`wasm32-unknown-unknown` target when the `atomics` feature is
implemented. This, however, comes with a notable caveat of that it
requires a new feature of the standard library, `wasm-bindgen-threads`,
to be enabled.
Thread local storage for wasm (when `atomics` are enabled and there's
actually more than one thread) is powered by the assumption that an
external entity can fill in some information for us. It's not currently
clear who will fill in this information nor whose responsibility it
should be long-term. In the meantime there's a strategy being gamed out
in the `wasm-bindgen` project specifically, and the hope is that we can
continue to test and iterate on the standard library without committing
to a particular strategy yet.
As to the details of `wasm-bindgen`'s strategy, LLVM doesn't currently
have the ability to emit custom `global` values (thread locals in a
`WebAssembly.Module`) so we leverage the `wasm-bindgen` CLI tool to do
it for us. To that end we have a few intrinsics, assuming two global values:
* `__wbindgen_current_id` - gets the current thread id as a 32-bit
integer. It's `wasm-bindgen`'s responsibility to initialize this
per-thread and then inform libstd of the id. Currently `wasm-bindgen`
performs this initialization as part of the `start` function.
* `__wbindgen_tcb_{get,set}` - in addition to a thread id it's assumed
that there's a global available for simply storing a pointer's worth
of information (a thread control block, which currently only contains
thread local storage). This would ideally be a native `global`
injected by LLVM, but we don't have a great way to support that right
now.
To reiterate, this is all intended to be unstable and purely intended
for testing out Rust on the web with threads. The story is very likely
to change in the future and we want to make sure that we're able to do
that!
2018-10-10 08:10:25 +02:00
|
|
|
|
|
|
|
|
# An off-by-default features to enable libstd to assume that wasm-bindgen is in
|
|
|
|
|
# the environment for hooking up some thread-related information like the
|
|
|
|
|
# current thread id and accessing/getting the current thread's TCB
|
|
|
|
|
wasm-bindgen-threads = []
|
