| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Previously this threshold when testing was 100ns, but the Windows
documentation states:
> which is a high resolution (<1us) time stamp
which presumably means that we could have up to 1us resolution, which
means that 100ns doesn't capture "equivalent" time intervals due to
various bits of rounding here and there.
It's hoped that this..
Closes #56034
|
|
This commit, after reverting #55359, applies a different fix for #46775
while also fixing #55775. The basic idea was to go back to pre-#55359
libstd, and then fix #46775 in a way that doesn't expose #55775.
The issue described in #46775 boils down to two problems:
* First, the global environment is reset during `exec` but, but if the
`exec` call fails then the global environment was a dangling pointer
into free'd memory as the block of memory was deallocated when
`Command` is dropped. This is fixed in this commit by installing a
`Drop` stack object which ensures that the `environ` pointer is
preserved on a failing `exec`.
* Second, the global environment was accessed in an unsynchronized
fashion during `exec`. This was fixed by ensuring that the
Rust-specific environment lock is acquired for these system-level
operations.
Thanks to Alex Gaynor for pioneering the solution here!
Closes #55775
Co-authored-by: Alex Gaynor <alex.gaynor@gmail.com>
|
|
This reverts commit 36fe3b605a7a7143a14565272140ba1b43c1b041.
|
|
Instead, pass the environment to execvpe, so the kernel can apply it directly to the new process. This avoids a use-after-free in the case where exec'ing the new process fails for any reason, as well as a race condition if there are other threads alive during the exec.
|
|
Fix doc for new copysign functions
Thanks to @LukasKalbertodt for catching this. Addresses a comment raised in #55169 after it was merged.
|
|
fix typos in various places
|
|
r=joshtriplett
Clarified code example in char primitive doc
The example was not as clear as it could be because it was making an assumption about the structure of the data in order to multiply the number of elements in the slice by the item size. This change demonstrates the idea more straightforwardly, without needing a calculation, by just comparing the size of the slices.
|
|
Documents `From` implementations for `Stdio`
This PR solves part of #51430 by adding a basic summary and an example to each `impl From` inside `process` module (`ChildStdin`, `ChildStdout`, `ChildStderr`, `File`).
It does not document if the conversions allocate memory and how expensive they are.
|
|
r=GuillaumeGomez
update tcp stream documentation
A small styling issue that seemed inconsistent here when compared to other places (such as https://doc.rust-lang.org/beta/std/net/struct.TcpListener.html).
|
|
Gradually expanding libstd's keyword documentation
I'm working on adding new keywords to the documentation and refreshing the incomplete older ones, and I'm hoping that I can eventually add all the standalone-usable keywords after a bunch of incremental work. It would be cool to see the keywords section of std's docs be a definitive reference as to what each keyword means when you see it, and that's what I'm aiming towards with this work.
I'm far from a Rust expert so there will inevitably be things to fix in this, also I'm not sure if this should be a bunch of quickly-merged PRs or one gradually-updated PR that gets merged once it's done.
|
|
Thanks to @LukasKalbertodt for catching this. Addresses a comment
raised in #55169 after it was merged.
|
|
Add a basic summary and an example to From `ChildStdin`, `ChildStdout`,
`ChildStderr`, `File` implementations.
|
|
This was added in the fortnight this PR spent stale. I'm hoping this
one-liner fixes it.
|
|
|
|
The example was not as clear as it could be because it was making an assumption about the structure of the data in order to multiply the number of collection elements by the item size. This change demonstrates the idea more straightforwardly, without the calculation.
|
|
Prefer unwrap_or_else to unwrap_or in case of function calls/allocations
The contents of `unwrap_or` are evaluated eagerly, so it's not a good pick in case of function calls and allocations. This PR also changes a few `unwrap_or`s with `unwrap_or_default`.
An added bonus is that in some cases this change also reveals if the object it's called on is an `Option` or a `Result` (based on whether the closure takes an argument).
|
|
Add a `copysign` function to f32 and f64
This patch adds a `copysign` function to the float primitive types. It is an exceptionally useful function for writing efficient numeric code, as it often avoids branches, is auto-vectorizable, and there are efficient intrinsics for most platforms.
I think this might work as-is, as the relevant `copysign` intrinsic is already used internally for the implementation of `signum`. It's possible that an implementation might be needed in japaric/libm for portability across all platforms, in which case I'll do that also.
Part of the work towards #55107
|
|
|
|
Added a #[must_use] annotation on copysign, per review feedback.
|
|
improve documentation on std::thread::sleep
|
|
I improved the f32 version and made a copy-paste error for f64.
|
|
This patch adds a `copysign` function to the float primitive types.
It is an exceptionally useful function for writing efficient numeric
code, as it often avoids branches, is auto-vectorizable, and there
are efficient intrinsics for most platforms.
I think this might work as-is, as the relevant `copysign` intrinsic
is already used internally for the implementation of `signum`. It's
possible that an implementation might be needed in japaric/libm for
portability across all platforms, in which case I'll do that also.
Part of the work towards #55107
|
|
The eprintln! link was incorrectly linking to eprint! instead
|
|
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!
|
|
"(using ..." doesn't have the matching ")"
Fixes #54948.
|
|
doc fix: it's auto traits that make for automatic implementations
Being a marker trait is not good enough (that just means "no items in the trait").
r? @alexcrichton who [originally wrote these docs](https://github.com/RalfJung/rust/commit/0a13f1abafe70cddf34bf2b2ba3946c418ed6241).
|
|
Fix tracking issue for Once::is_completed
https://github.com/rust-lang/rust/pull/53027 was merged without a tracking issue. I just filed https://github.com/rust-lang/rust/issues/54890. CC @matklad
|
|
r=QuietMisdreavus
Documents reference equality by address (#54197)
Clarification of the use of `ptr::eq` to test equality of references via address by pointer coercion, regarding issue #54197 .
The same example as in `ptr::eq` docs is shown here to clarify that
`PartialEq` compares values pointed-to instead of via address (which can be desired in some cases)
|
|
|
|
|
|
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!
|
|
|
|
Fixes #54948.
|
|
|
|
Remove unnecessary comma in `libstd/thread/mod.rs` doc comment
Fix typo in `libstd/thread/mod.rs` doc comment: remove unnecessary comma.
|
|
Add doc for impl From for Error
As part of issue #51430 (cc @skade).
The impl is very simple, let me know if we need to go into any details.
|
|
oli-obk:mögen_konstante_funktionen_doch_bitte_endlich_stabil_sein, r=Centril
Stabilize `min_const_fn`
tracking issue: #53555
r? @Centril
|
|
|
|
rustc: Allow `#[no_mangle]` anywhere in a crate
This commit updates the compiler to allow the `#[no_mangle]` (and
`#[export_name]` attributes) to be located anywhere within a crate.
These attributes are unconditionally processed, causing the compiler to
always generate an exported symbol with the appropriate name.
After some discussion on #54135 it was found that not a great reason
this hasn't been allowed already, and it seems to match the behavior
that many expect! Previously the compiler would only export a
`#[no_mangle]` symbol if it were *publicly reachable*, meaning that it
itself is `pub` and it's otherwise publicly reachable from the root of
the crate. This new definition is that `#[no_mangle]` *is always
reachable*, no matter where it is in a crate or whether it has `pub` or
not.
This should make it much easier to declare an exported symbol with a
known and unique name, even when it's an internal implementation detail
of the crate itself. Note that these symbols will persist beyond LTO as
well, always making their way to the linker.
Along the way this commit removes the `private_no_mangle_functions` lint
(also for statics) as there's no longer any need to lint these
situations. Furthermore a good number of tests were updated now that
symbol visibility has been changed.
Closes #54135
|
|
This commit updates the compiler to allow the `#[no_mangle]` (and
`#[export_name]` attributes) to be located anywhere within a crate.
These attributes are unconditionally processed, causing the compiler to
always generate an exported symbol with the appropriate name.
After some discussion on #54135 it was found that not a great reason
this hasn't been allowed already, and it seems to match the behavior
that many expect! Previously the compiler would only export a
`#[no_mangle]` symbol if it were *publicly reachable*, meaning that it
itself is `pub` and it's otherwise publicly reachable from the root of
the crate. This new definition is that `#[no_mangle]` *is always
reachable*, no matter where it is in a crate or whether it has `pub` or
not.
This should make it much easier to declare an exported symbol with a
known and unique name, even when it's an internal implementation detail
of the crate itself. Note that these symbols will persist beyond LTO as
well, always making their way to the linker.
Along the way this commit removes the `private_no_mangle_functions` lint
(also for statics) as there's no longer any need to lint these
situations. Furthermore a good number of tests were updated now that
symbol visibility has been changed.
Closes #54135
|
|
|
|
|
|
Expand the documentation for the `std::sync` module
I've tried to expand the documentation for Rust's synchronization primitives. The module level documentation explains why synchronization is required when working with a multiprocessor system,
and then links to the appropiate structure in this module.
Fixes #29377, since this should be the last item on the checklist (documentation for `Atomic*` was fixed in #44854, but not ticked off the checklist).
|
|
|
|
|
|
std: Start implementing wasm32 atomics
This commit is an initial start at implementing the standard library for
wasm32-unknown-unknown with the experimental `atomics` feature enabled. None of
these changes will be visible to users of the wasm32-unknown-unknown target
because they all require recompiling the standard library. The hope with this is
that we can get this support into the standard library and start iterating on it
in-tree to enable experimentation.
Currently there's a few components in this PR:
* Atomic fences are disabled on wasm as there's no corresponding atomic op and
it's not clear yet what the convention should be, but this will change in the
future!
* Implementations of `Mutex`, `Condvar`, and `RwLock` were all added based on
the atomic intrinsics that wasm has.
* The `ReentrantMutex` and thread-local-storage implementations panic currently
as there's no great way to get a handle on the current thread's "id" yet.
Right now the wasm32 target with atomics is unfortunately pretty unusable,
requiring a lot of manual things here and there to actually get it operational.
This will likely continue to evolve as the story for atomics and wasm unfolds,
but we also need more LLVM support for some operations like custom `global`
directives for this to work best.
|
|
r=GuillaumeGomez
Add doc for impl From for Std Error
As part of issue #51430 (cc @skade).
I am not sure if it is going to a correct direction so put up here so that people can comment.
|
|
|
