Added table containing the system calls used by Instant and SystemTime.
# Description
See #32626 for a discussion on documenting system calls used by Instant and SystemTime.
## Changes
- Added a table containing the system calls used by each platform.
EDIT: If I can format this table better (due to the large links) please let me know.
I'd also be happy to learn a quick command to generate the docs on my host machine! Currently I am using: `python x.py doc --stage 0 src/libstd` but that gives me some `unrecognized intrinsic` errors. Advice is always welcome :)
closes#32626
std: Add a `backtrace` module
This commit adds a `backtrace` module to the standard library, as
designed in [RFC 2504]. The `Backtrace` type is intentionally very
conservative, effectively only allowing capturing it and printing it.
Additionally this commit also adds a `backtrace` method to the `Error`
trait which defaults to returning `None`, as specified in [RFC 2504].
More information about the design here can be found in [RFC 2504] and in
the [tracking issue].
Implementation-wise this is all based on the `backtrace` crate and very
closely mirrors the `backtrace::Backtrace` type on crates.io. Otherwise
it's pretty standard in how it handles everything internally.
[RFC 2504]: https://github.com/rust-lang/rfcs/blob/master/text/2504-fix-error.md
[tracking issue]: https://github.com/rust-lang/rust/issues/53487
cc #53487
vxWorks: set DEFAULT_MIN_STACK_SIZE to 256K and use min_stack to pass initial stack size to rtpSpawn
vxWorks: set DEFAULT_MIN_STACK_SIZE to 256K and use min_stack to pass initial stack size to rtpSpawn
r? @alexcrichton
cc @n-salim
This commit adds a `backtrace` module to the standard library, as
designed in [RFC 2504]. The `Backtrace` type is intentionally very
conservative, effectively only allowing capturing it and printing it.
Additionally this commit also adds a `backtrace` method to the `Error`
trait which defaults to returning `None`, as specified in [RFC 2504].
More information about the design here can be found in [RFC 2504] and in
the [tracking issue].
Implementation-wise this is all based on the `backtrace` crate and very
closely mirrors the `backtrace::Backtrace` type on crates.io. Otherwise
it's pretty standard in how it handles everything internally.
[RFC 2504]: https://github.com/rust-lang/rfcs/blob/master/text/2504-fix-error.md
[tracking issue]: https://github.com/rust-lang/rust/issues/53487
cc #53487
Stabilize `bind_by_move_pattern_guards` in Rust 1.39.0
Closes https://github.com/rust-lang/rust/issues/15287.
After stabilizing `#![feature(bind_by_move_pattern_guards)]`, you can now use bind-by-move bindings in patterns and take references to those bindings in `if` guards of `match` expressions. For example, the following now becomes legal:
```rust
fn main() {
let array: Box<[u8; 4]> = Box::new([1, 2, 3, 4]);
match array {
nums
// ---- `nums` is bound by move.
if nums.iter().sum::<u8>() == 10
// ^------ `.iter()` implicitly takes a reference to `nums`.
=> {
drop(nums);
// --------- Legal as `nums` was bound by move and so we have ownership.
}
_ => unreachable!(),
}
}
```
r? @matthewjasper
libstd fuchsia fixes
This fixes two bugs in libstd on Fuchsia:
- `zx_time_t` was changed to an `i64`, but this never made it into libstd
- When spawning processes where any of the stdio were null, libstd attempts to open `/dev/null`, which doesn't exist on Fuchsia
r? @cramertj
Support both static and dynamic linking mode in testing for vxWorks
1. Support both static and dynamic linking mode in testing for vxWorks
2. Ignore unsupported test cases: net:tcp:tests:timeouts and net:ucp:tests:timeouts
r? @alexcrichton
std: Improve downstream codegen in `Command::env`
This commit rejiggers the generics used in the implementation of
`Command::env` with the purpose of reducing the amount of codegen that
needs to happen in consumer crates, instead preferring to generate code
into libstd.
This was found when profiling the compile times of the `cc` crate where
the binary rlib produced had a lot of `BTreeMap` code compiled into it
but the crate doesn't actually use `BTreeMap`. It turns out that
`Command::env` is generic enough to codegen the entire implementation in
calling crates, but in this case there's no performance concern so it's
fine to compile the code into the standard library.
This change is done by removing the generic on the `CommandEnv` map
which is intended to handle case-insensitive variables on Windows.
Instead now a generic isn't used but rather a `use` statement defined
per-platform is used.
With this commit a debug build of `Command::new("foo").env("a", "b")`
drops from 21k lines of LLVM IR to 10k.
This commit rejiggers the generics used in the implementation of
`Command::env` with the purpose of reducing the amount of codegen that
needs to happen in consumer crates, instead preferring to generate code
into libstd.
This was found when profiling the compile times of the `cc` crate where
the binary rlib produced had a lot of `BTreeMap` code compiled into it
but the crate doesn't actually use `BTreeMap`. It turns out that
`Command::env` is generic enough to codegen the entire implementation in
calling crates, but in this case there's no performance concern so it's
fine to compile the code into the standard library.
This change is done by removing the generic on the `CommandEnv` map
which is intended to handle case-insensitive variables on Windows.
Instead now a generic isn't used but rather a `use` statement defined
per-platform is used.
With this commit a debug build of `Command::new("foo").env("a", "b")`
drops from 21k lines of LLVM IR to 10k.
Fix unlock ordering in SGX synchronization primitives
Avoid holding spinlocks during usercalls. This should avoid deadlocks in certain pathological scheduling cases.
cc @mzohreva @parthsane
r? @alexcrichton
Added warning around code with reference to uninit bytes
Officially, uninitialized integers, and therefore, Rust references to them are _invalid_ (note that this may evolve into official defined behavior (_c.f._, https://github.com/rust-lang/unsafe-code-guidelines/issues/71)).
However, `::std` uses references to uninitialized integers when working with the `Read::initializer` feature (#42788), since it relies on this unstably having defined behavior with the current implementation of the compiler (IIUC).
Hence the comment to disincentivize people from using this pattern outside the standard library.
Mazdak Farrokhzad