| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Changed instant is earlier to instant is later
Fixed the documentation issue from #64322
|
|
Always show backtrace on Fuchsia
r? @alexcrichton
cc @jakeehrlich
|
|
|
|
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
|
|
|
|
|
|
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`.
|
|
|
|
|
|
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
|
|
Summary:
Invoking `rev` does not add a trailing newline when none is present in
the input (at least on my Debian). Nearby examples use `echo` rather
than `rev`, which probably explains the source of the discrepancy.
Also, a `mut` qualifier is unused.
Test Plan:
Copy the code block into <https://play.rust-lang.org> with a `fn main`
wrapper, and run it. Note that it compiles and runs cleanly; prior to
this commit, it would emit an `unused_mut` warning and then panic.
wchargin-branch: stdio-piped-docs
|
|
Use backtrace formatting from the backtrace crate
r? @alexcrichton
|
|
|
|
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
|
|
|
|
|
|
Add Fuchsia to actually_monotonic
Fuchsia provides a fully monotonic clock.
Fix https://github.com/rust-lang/rust/issues/64196
cc @joshlf @tmandry
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.
|
|
Use wasi crate for Core API
Blocked by: CraneStation/rust-wasi#5
Blocks: rust-lang/libc#1461
cc @sunfishcode @alexcrichton
|
|
sync with rust-lang/rust master branch
|
|
Fuchsia provides a fully monotonic clock.
|
|
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
|
|
danielhenrymantilla:add_comment_about_uninit_integers, r=Centril
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.
|
|
Stabilize checked_duration_since for 1.38.0
Looks like it has already found some use in projects.
Resolves #58402.
|
|
|
|
Resolves #58402.
|
|
sync with rust-lang/rust branch master
|
|
|
|
|
|
|
|
initial stack size to rtpSpawn
|
|
Update sync condvar doc style
|
|
Update BufWriter example to include call to flush()
I was playing with a writing a Huffman encoder/decoder and was getting weird corruptions and truncations. I finally realized it was was because `BufWriter` was swallowing write errors 😬. I've found Rust to generally be explicit and err on the safe side, so I definitely found this unintuitive and not "rustic".
https://twitter.com/johnterickson/status/1159514988123312128
|
|
remove directory libstd/sys/vxworks/backtrace which is not used any more
r? @alexcrichton
cc @n-salim
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Match the loop examples
The idea is to show the usefulness of the expression side by side.
|
|
|
|
|
