| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
Remove references to `StaticMutex` which got removed a while ago
`StaticMutex` got removed two years ago with https://github.com/rust-lang/rust/pull/34705, but still got referenced in some comments and even an error explanation.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Specify reentrancy gurantees of `Once::call_once`
I don't think the docs are clear about what happens in the following code
```rust
static INIT: Once = ONCE_INIT;
INIT.call_once(|| INIT.call_once(|| println!("huh?")));
```
[Playground](https://play.rust-lang.org/?gist=15dde1f68a6ede263c7250c36977eade&version=stable&mode=debug&edition=2015)
Let's "specify" the behavior to make it clear that the current behavior (deadlock I think?) is not a strict guarantee.
|
|
|
|
|
|
|
|
|
|
Switch to bootstrapping from 1.29 beta
r? @alexcrichton
|
|
Don't commit thread stack on Windows
On Windows, there is a system level resource limitation called commit limit, which is roughly the sum of physical memory + paging files[1]. `CreateThread` by default commits the stack size[2], which unnecessarily takes such resource from the shared limit.
This PR changes it to only reserve the stack size rather than commit it. Reserved memory would only take the address space of the current process until it's actually accessed.
This should make the behavior on Windows match other platforms, and is also a pretty standard practice on Windows nowadays.
[1] https://blogs.technet.microsoft.com/markrussinovich/2008/11/17/pushing-the-limits-of-windows-virtual-memory/
[2] https://docs.microsoft.com/zh-cn/windows/desktop/api/processthreadsapi/nf-processthreadsapi-createthread
|
|
|
|
|
|
Add targets for HermitCore (https://hermitcore.org) to the Rust compiler and port libstd to it.
As a start, the port uses the simplest possible configuration (no jemalloc, abort on panic) and makes use of existing Unix-specific code wherever possible.
It adds targets for x86_64 (current main HermitCore platform) and aarch64 (HermitCore platform under development).
Together with the patches to "liblibc" (https://github.com/rust-lang/libc/pull/1048) and llvm (https://github.com/rust-lang/llvm/pull/122), this enables HermitCore applications to be written in Rust.
|
|
Clarify thread::park semantics
It took me quite some time to realize that the example is not actually racy, so let's clarify it? :-)
|
|
Remove unstable and deprecated APIs
|
|
Document From trait implementations for OsStr, OsString, CString, and CStr
As part of issue #51430 (cc @skade).
The allocation and copy claims should be double-checked.
r? @steveklabnik
|
|
|
|
|
|
|
|
Its former contents are now in libcore.
|
|
port libstd to it.
As a start, the port uses the simplest possible configuration (no jemalloc, abort on panic)
and makes use of existing Unix-specific code wherever possible.
It adds targets for x86_64 (current main HermitCore platform) and aarch64 (HermitCore platform
under development).
Together with the patches to "liblibc" and "llvm", this enables HermitCore applications to be
written in Rust.
|
|
Don't format!() string literals
Prefer `to_string()` to `format!()` take 2, this time targetting string literals. In some cases (`&format!("...")` -> `"..."`) also removes allocations. Occurences of `format!("")` are changed to `String::new()`.
|
|
|
|
Replace push loops with extend() where possible
Or set the vector capacity where I couldn't do it.
According to my [simple benchmark](https://gist.github.com/ljedrz/568e97621b749849684c1da71c27dceb) `extend`ing a vector can be over **10 times** faster than `push`ing to it in a loop:
10 elements (6.1 times faster):
```
test bench_extension ... bench: 75 ns/iter (+/- 23)
test bench_push_loop ... bench: 458 ns/iter (+/- 142)
```
100 elements (11.12 times faster):
```
test bench_extension ... bench: 87 ns/iter (+/- 26)
test bench_push_loop ... bench: 968 ns/iter (+/- 3,528)
```
1000 elements (11.04 times faster):
```
test bench_extension ... bench: 311 ns/iter (+/- 9)
test bench_push_loop ... bench: 3,436 ns/iter (+/- 233)
```
Seems like a good idea to use `extend` as much as possible.
|
|
|
|
Prefer to_string() to format!()
Simple benchmarks suggest in some cases it can be faster by even 37%:
```
test converting_f64_long ... bench: 339 ns/iter (+/- 199)
test converting_f64_short ... bench: 136 ns/iter (+/- 34)
test converting_i32_long ... bench: 87 ns/iter (+/- 16)
test converting_i32_short ... bench: 87 ns/iter (+/- 49)
test converting_str ... bench: 54 ns/iter (+/- 15)
test formatting_f64_long ... bench: 349 ns/iter (+/- 176)
test formatting_f64_short ... bench: 145 ns/iter (+/- 14)
test formatting_i32_long ... bench: 98 ns/iter (+/- 14)
test formatting_i32_short ... bench: 93 ns/iter (+/- 15)
test formatting_str ... bench: 86 ns/iter (+/- 23)
```
|
|
Misc cleanups
|
|
|
|
Impl Send & Sync for JoinHandle
This is just a cosmetic change - it slightly relaxes and clarifies the public API without effectively promising any new guarantees.
Currently we have [these auto trait implementations](https://doc.rust-lang.org/nightly/std/thread/struct.JoinHandle.html#synthetic-implementations):
```rust
impl<T: Send> Send for JoinHandle<T> {}
impl<T: Sync> Sync for JoinHandle<T> {}
```
Bound `T: Send` doesn't make much sense because `JoinHandle<T>` can be created only when `T: Send`. Note that [`JoinHandle::<T>::join`](https://doc.rust-lang.org/nightly/std/thread/struct.JoinHandle.html#method.join) doesn't require `T: Send` so why should the `Send` impl?
And the `Sync` impl doesn't need `T: Sync` because `JoinHandle<T>` cannot even share `T` - it can only send it to the thread that calls `join`.
|
|
Rollup of bare_trait_objects PRs
All deny attributes were moved into bootstrap so they can be disabled with a line of config.
Warnings for external tools are allowed and it's up to the tool's maintainer to keep it warnings free.
r? @Mark-Simulacrum
cc @ljedrz @kennytm
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
'ljedrz/dyn_libterm' into dyn-rollup
|
