| Age | Commit message (Collapse) | Author | Lines |
|
Unix sockets on redox
This is done using the ipcd daemon. It's not exactly like unix sockets because there is not actually a physical file for the path, but it's close enough for a basic implementation :)
This allows mio-uds and tokio-uds to work with a few modifications as well, which is exciting!
|
|
|
|
- [std: Rewrite the `sync` modulehttps://github.com/rust-lang/rust/commit/71d4e77db8ad4b6d821da7e5d5300134ac95974e) (Nov 2014)
```diff
- pub fn doit(&self, f: ||) {
+ pub fn doit(&'static self, f: ||) {
```
> ```text
> The second layer is the layer provided by `std::sync` which is intended to be
> the thinnest possible layer on top of `sys_common` which is entirely safe to
> use. There are a few concerns which need to be addressed when making these
> system primitives safe:
>
> * Once used, the OS primitives can never be **moved**. This means that they
> essentially need to have a stable address. The static primitives use
> `&'static self` to enforce this, and the non-static primitives all use a
> `Box` to provide this guarantee.
> ```
The author of this diff is @alexcrichton. `sync::Once` contains only a pointer to (privately hidden) `Waiter`s, which are all stack-allocated. The `'static` bound to `sync::Once` is thus unnecessary to guarantee that any OS primitives are non-relocatable.
See https://internals.rust-lang.org/t/sync-once-per-instance/7918 for more context.
|
|
|
|
|
|
This to-be-stable attribute is equivalent to `#[lang = "oom"]`.
It is required when using the alloc crate without the std crate.
It is called by `handle_alloc_error`, which is in turned called
by "infallible" allocations APIs such as `Vec::push`.
|
|
of the declaration in liballoc
This turned out to be important on Windows.
Calling `handle_alloc_error(Layout::new::<[u8; 42]>())` caused:
```
Exception thrown at 0x00007FF7C70DC399 in a.exe: 0xC0000005:
Access violation reading location 0x000000000000002A.
```
0x2A equals 42, so it looks like the `Layout::size` field of type `usize`
was interpreted as a pointer to read from.
|
|
Add the `alloc::prelude` module
It contains the re-exports that are in `std::prelude::v1` but not in `core::prelude::v1`.
Calling it prelude is somewhat of a misnomer since (unlike those modules in `std` or `core`) its contents are never implicitly imported in modules. Rather it is intended to be used with an explicit glob import like `use alloc::prelude::*;`. However there is precedent for the same misnomer with `std::io::prelude`, for example.
This new module is unstable with the same feature name as the `alloc` care. They are proposed for stabilization together in RFC https://github.com/rust-lang/rfcs/pull/2480.
|
|
The original example didn't check the return value of `write()`, didn't
flush the writer, and didn't properly demonstrate the buffering.
Fixes #51621.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Deprecate `std::env::home_dir` and fix incorrect documentation
Compare `std::env::home_dir`s claim:
> Returns the value of the 'HOME' environment variable if it is set and not equal to the empty string.
... with its actual behavior:
```
std::env::set_var("HOME", "");
println!("{:?}", std::env::var_os("HOME")); // Some("")
println!("{:?}", std::env::home_dir()); // Some("")
```
The implementation is incorrect in two cases:
- `$HOME` is set, but empty.
- An entry for the user exists in `/etc/passwd`, but it's `pw_dir` is empty.
In both cases Rust considers an empty string to be a valid home directory. This contradicts the documentation, and is wrong in general.
|
|
|
|
Haiku: several smaller fixes to build and run rust on Haiku
This PR combines three small patches that help Rust build and run on the Haiku platform. These patches do not intend to impact other platforms.
|
|
Implements #51908.
|
|
Make Stdio handle UnwindSafe
Closes #51863
This is my first compiler PR. Thanks Niko for the mentor help!
r? @nikomatsakis
|
|
Add read_exact_at and write_all_at methods to FileExt on unix
This PR adds `FileExt::read_exact_at()` and `FileExt::write_all_at()`, which are to `read_at()` and `write_at()` as `read_exact()` and `write_all()` are to `read()` and `write()`. This allows the user to not have to deal with `ErrorKind::Interrupted` and calling the functions in a loop.
I was unsure as to how to mark these new methods so I marked them `unstable`, please let me know if I should have done it differently.
I asked in Discord and was told that as this change is small it does not require an RFC.
|
|
|
|
Implement always-fallible TryFrom for usize/isize conversions that are infallible on some platforms
This reverts commit 837d6c70233715a0ae8e15c703d40e3046a2f36a "Remove TryFrom impls that might become conditionally-infallible with a portability lint".
This fixes #49415 by adding (restoring) missing `TryFrom` impls for integer conversions to or from `usize` or `isize`, by making them always fallible at the type system level (that is, with `Error=TryFromIntError`) even though they happen to be infallible on some platforms (for some values of `size_of::<usize>()`).
They had been removed to allow the possibility to conditionally having some of them be infallible `From` impls instead, depending on the platforms, and have the [portability lint](https://github.com/rust-lang/rfcs/pull/1868) warn when they are used in code that is not already opting into non-portability. For example `#[allow(some_lint)] usize::from(x: u64)` would be valid on code that only targets 64-bit platforms.
This PR gives up on this possiblity for two reasons:
* Based on discussion with @aturon, it seems that the portability lint is not happening any time soon. It’s better to have the conversions be available *at all* than keep blocking them for so long. Portability-lint-gated platform-specific APIs can always be added separately later.
* For code that is fine with fallibility, the alternative would force it to opt into "non-portability" even though there would be no real portability issue.
|
|
|
|
|
|
Use in-tree libbacktrace on Fuchsia
cc @abarth
r? @alexcrichton
(welcome back! :smile: )
|
|
Fix inconsequential typo in GlobalAlloc doc example
|
|
Fix some doc links
The futures crate CI always fails because of these intra doc links. I hope that this will fix this issue.
r? @steveklabnik
@cramertj
Edit: I added @steveklabnik as reviewer because this PR also adjusts a link in `src/libstd/error.rs`
|
|
Bootstrap from 1.28.0 beta
|
|
|
|
Implement PartialEq between &str and OsString
This fixes #49854.
It allows equality comparison between `OsString` values and `str` references, such as `os_string == "something"`.
|
|
|
|
|
|
|
|
This matches std::collections
|
|
|
|
Allows for example `os_string == "something"`
|
|
Add a fallback for stacktrace printing for older Windows versions.
Some time ago we switched stack inspection functions of dbghelp.dll to their newer alternatives that also capture inlined context.
Unfortunately, said new alternatives are not present in older dbghelp.dll versions.
In particular Windows 7 at the time of writing has dbghelp.dll version 6.1.7601 from 2010, that lacks StackWalkEx and friends.
Tested on my Windows 7 - both msvc and gnu versions produce a readable stacktrace.
Fixes #50138
|
|
park/park_timeout: prohibit spurious wakeups in next park
<pre><code>
// The implementation currently uses the trivial strategy of a Mutex+Condvar
// with wakeup flag, which does not actually allow spurious wakeups.
</pre></code>
Because does not actually allow spurious wakeups.
so we have let thread.inner.cvar.wait(m) in the loop to prohibit spurious wakeups.
but if notified after we locked, this notification doesn't be consumed, it return, the next park will consume this notification...this is also 'spurious wakeup' case, 'one unpark() wakeups two park()'.
We should improve this situation:
`thread.inner.state.store(EMPTY, SeqCst);`
|
|
|
|
|
|
|
|
|
|
.. and pass them around in BacktraceContext.
|
|
.. rather than having them be one giant match statement.
|
|
PR #47252 switched stack inspection functions of dbghelp.dll
to their newer alternatives that also capture inlined context.
Unfortunately, said new alternatives are not present in older
dbghelp.dll versions.
In particular Windows 7 at the time of writing has dbghelp.dll
version 6.1.7601 from 2010, that lacks StackWalkEx and friends.
Fixes #50138
|
|
Fix the error reference for LocalKey::try_with
There's no such thing as `ThreadLocalError` and the method obviously returns `AccessError`, so adjusting (probably only outdated docs).
|
|
Document round-off error in `.mod_euc()`-method, see issue #50179
Due to a round-off error the method `.mod_euc()` of both `f32` and `f64` can produce mathematical invalid outputs. If `self` in magnitude is much small than the modulus `rhs` and negative, `self + rhs` in the first branch cannot be represented in the given precision and results into `rhs`. In the mathematical strict sense, this breaks the definition. But given the limitation of floating point arithmetic it can be thought of the closest representable value to the true result, although it is not strictly in the domain `[0.0, rhs)` of the function. It is rather the left side asymptotical limit. It would be desirable that it produces the mathematical more sound approximation of `0.0`, the right side asymptotical limit. But this breaks the property, that `self == self.div_euc(rhs) * rhs + a.mod_euc(rhs)`.
The discussion in issue #50179 did not find an satisfying conclusion to which property is deemed more important. But at least we can document the behaviour. Which this pull request does.
|
|
|
|
|