2016-01-21 23:19:23 +00:00
|
|
|
[package]
|
|
|
|
|
authors = ["The Rust Project Developers"]
|
|
|
|
|
name = "std"
|
|
|
|
|
version = "0.0.0"
|
|
|
|
|
build = "build.rs"
|
2019-05-09 22:37:37 +00:00
|
|
|
license = "MIT OR Apache-2.0"
|
2017-10-31 19:57:27 +00:00
|
|
|
repository = "https://github.com/rust-lang/rust.git"
|
2017-10-31 20:10:10 +00:00
|
|
|
description = "The Rust Standard Library"
|
2019-02-10 19:23:21 +00:00
|
|
|
edition = "2018"
|
2016-01-21 23:19:23 +00:00
|
|
|
|
|
|
|
|
[lib]
|
|
|
|
|
name = "std"
|
|
|
|
|
path = "lib.rs"
|
|
|
|
|
crate-type = ["dylib", "rlib"]
|
|
|
|
|
|
|
|
|
|
[dependencies]
|
|
|
|
|
alloc = { path = "../liballoc" }
|
2019-06-14 09:00:37 +00:00
|
|
|
cfg-if = { version = "0.1.8", features = ['rustc-dep-of-std'] }
|
2016-11-24 02:49:54 +00: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-08 23:18:40 +00:00
|
|
|
panic_abort = { path = "../libpanic_abort" }
|
2016-01-21 23:19:23 +00:00
|
|
|
core = { path = "../libcore" }
|
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 18:02:22 +00:00
|
|
|
libc = { version = "0.2.51", default-features = false, features = ['rustc-dep-of-std'] }
|
2019-06-06 20:27:07 +00:00
|
|
|
compiler_builtins = { version = "0.1.16" }
|
2017-02-13 09:57:50 +00: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-08 23:18:40 +00:00
|
|
|
unwind = { path = "../libunwind" }
|
2019-06-12 16:31:32 +00:00
|
|
|
hashbrown = { version = "0.5.0", features = ['rustc-dep-of-std'] }
|
2019-08-29 17:13:15 +00:00
|
|
|
wasi = { version = "0.7.0", features = ['rustc-dep-of-std', 'alloc'] }
|
2019-05-15 14:30:15 +00:00
|
|
|
|
|
|
|
|
[dependencies.backtrace]
|
2019-08-19 13:13:18 +00:00
|
|
|
version = "0.3.35"
|
2019-05-15 14:30:15 +00:00
|
|
|
default-features = false # don't use coresymbolication on OSX
|
|
|
|
|
features = [
|
|
|
|
|
"rustc-dep-of-std", # enable build support for integrating into libstd
|
|
|
|
|
"dbghelp", # backtrace/symbolize on MSVC
|
|
|
|
|
"libbacktrace", # symbolize on most platforms
|
|
|
|
|
"libunwind", # backtrace on most platforms
|
|
|
|
|
"dladdr", # symbolize on platforms w/o libbacktrace
|
|
|
|
|
]
|
|
|
|
|
optional = true
|
2016-01-21 23:19:23 +00:00
|
|
|
|
2017-11-01 19:32:13 +00:00
|
|
|
[dev-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 05:52:50 +00:00
|
|
|
rand = "0.6.1"
|
2017-11-01 19:32:13 +00:00
|
|
|
|
2017-04-17 20:22:16 +00:00
|
|
|
[target.x86_64-apple-darwin.dependencies]
|
|
|
|
|
rustc_asan = { path = "../librustc_asan" }
|
|
|
|
|
rustc_tsan = { path = "../librustc_tsan" }
|
|
|
|
|
|
2016-12-30 04:28:11 +00:00
|
|
|
[target.x86_64-unknown-linux-gnu.dependencies]
|
2017-02-15 22:00:41 +00:00
|
|
|
rustc_asan = { path = "../librustc_asan" }
|
|
|
|
|
rustc_lsan = { path = "../librustc_lsan" }
|
|
|
|
|
rustc_msan = { path = "../librustc_msan" }
|
|
|
|
|
rustc_tsan = { path = "../librustc_tsan" }
|
2016-12-30 04:28:11 +00:00
|
|
|
|
2018-12-31 23:45:42 +00:00
|
|
|
[target.'cfg(any(all(target_arch = "wasm32", not(target_os = "emscripten")), all(target_vendor = "fortanix", target_env = "sgx")))'.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 05:52:50 +00:00
|
|
|
dlmalloc = { version = "0.1", features = ['rustc-dep-of-std'] }
|
2018-11-03 18:15:48 +00:00
|
|
|
|
2018-08-28 04:33:26 +00:00
|
|
|
[target.x86_64-fortanix-unknown-sgx.dependencies]
|
2018-12-19 11:56:17 +00:00
|
|
|
fortanix-sgx-abi = { version = "0.3.2", features = ['rustc-dep-of-std'] }
|
2018-08-28 04:33:26 +00:00
|
|
|
|
2016-01-21 23:19:23 +00:00
|
|
|
[build-dependencies]
|
2018-05-23 02:40:02 +00:00
|
|
|
cc = "1.0"
|
2016-01-21 23:19:23 +00:00
|
|
|
|
|
|
|
|
[features]
|
2019-05-20 18:00:34 +00:00
|
|
|
default = ["std_detect_file_io", "std_detect_dlsym_getauxval"]
|
2018-12-02 12:33:00 +00:00
|
|
|
|
2016-11-24 02:49:54 +00:00
|
|
|
panic-unwind = ["panic_unwind"]
|
2017-02-13 09:57:50 +00:00
|
|
|
profiler = ["profiler_builtins"]
|
2019-05-20 18:00:34 +00:00
|
|
|
compiler-builtins-c = ["alloc/compiler-builtins-c"]
|
2019-03-11 02:27:59 +00:00
|
|
|
llvm-libunwind = ["unwind/llvm-libunwind"]
|
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 06:10:25 +00:00
|
|
|
|
2018-11-29 21:06:10 +00:00
|
|
|
# Make panics and failed asserts immediately abort without formatting any message
|
|
|
|
|
panic_immediate_abort = ["core/panic_immediate_abort"]
|
|
|
|
|
|
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 06:10:25 +00: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 16:40:34 +00: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 06:10:25 +00:00
|
|
|
|
2019-07-15 11:53:44 +00:00
|
|
|
# Enable std_detect default features for stdarch/crates/std_detect:
|
|
|
|
|
# https://github.com/rust-lang/stdarch/blob/master/crates/std_detect/Cargo.toml
|
2019-02-11 21:00:10 +00:00
|
|
|
std_detect_file_io = []
|
|
|
|
|
std_detect_dlsym_getauxval = []
|
2019-03-12 17:58:30 +00:00
|
|
|
|
|
|
|
|
[package.metadata.fortanix-sgx]
|
|
|
|
|
# Maximum possible number of threads when testing
|
|
|
|
|
threads = 125
|
2019-06-06 21:06:49 +00:00
|
|
|
# Maximum heap size
|
|
|
|
|
heap_size = 0x8000000
|