| Age | Commit message (Collapse) | Author | Lines |
|
Fix incorrect `into_inner` link in docs.
Fixes https://github.com/rust-lang/rust/issues/42373.
|
|
This seems to have been undocumented. Mention this where the name is set
(Builder::name) and where the panic could happen (Builder::spawn).
Thread::new is private and I think the builder is the only user where
this matters. A short comment was added to "document" Thread::new too.
|
|
net::tcp::tests::connect_timeout_unroutable fails when the network
is unreachable, like on a laptop disconnected from wifi. Check for
this error and allow the test to pass.
Closes #44645
|
|
|
|
Mention that HashMap::new and HashSet::new do not allocate
The docs for `HashMap::with_capacity` and `HashSet::with_capacity` already say that
> If `capacity` is 0, the hash map/set will not allocate.
However, the docs for `::new` do not say that the initial capacity is 0, and thus promise that a call to `::new` alone does not allocate. This PR fixes that.
|
|
Ipv4Addr and Ipv6Addr convenience constructors.
Introduce convenience constructors for common types.
This introduces the following constructors:
* Ipv6Addr::localhost()
* Ipv6Addr::unspecified()
* Ipv4Addr::localhost()
* Ipv4Addr::unspecified()
The recently added `From` implementations were nice for avoiding the fallibility of conversions from strings like `"127.0.0.1".parse().unwrap()`, and `"::1".parse().unwrap()`, but while the Ipv4 version is roughly comparable in verbosity, the Ipv6 version lacks zero-segment elision, which makes it significantly more awkward: `[0, 0, 0, 0, 0, 0, 0, 0].into()`. While there isn't a clear way to introduce zero elision to type that can infallibly be converted into Ipv6 addresses, this PR resolves the problem for the two most commonly used addresses, which, incidentally, are the ones that suffer the most from the lack of zero-segment elision.
This change is dead simple, and introduces no backwards incompatibility.
See also, [this topic on the inernals board](https://internals.rust-lang.org/t/pre-rfc-convenience-ip-address-constructors/5878)
|
|
|
|
Individualize feature gates for const fn invocation
This PR changes the meaning of `#![feature(const_fn)]` so it is only required to declare a const fn but not to call one. Based on discussion at #24111. I was hoping we could have an FCP here in order to move that conversation forward.
This sets the stage for future stabilization of the constness of several functions in the standard library (listed below), so could someone please tag the lang team for review.
- `std::cell`
- `Cell::new`
- `RefCell::new`
- `UnsafeCell::new`
- `std::mem`
- `size_of`
- `align_of`
- `std::ptr`
- `null`
- `null_mut`
- `std::sync`
- `atomic`
- `Atomic{Bool,Ptr,Isize,Usize}::new`
- `once`
- `Once::new`
- primitives
- `{integer}::min_value`
- `{integer}::max_value`
Some other functions are const but they are also unstable or hidden, e.g. `Unique::new` so they don't have to be considered at this time.
After this stabilization, the following `*_INIT` constants in the standard library can be deprecated. I wasn't sure whether to include those deprecations in the current PR.
- `std::sync`
- `atomic`
- `ATOMIC_{BOOL,ISIZE,USIZE}_INIT`
- `once`
- `ONCE_INIT`
|
|
|
|
|
|
Fixes https://github.com/rust-lang/rust/issues/41452.
|
|
Most users would expect set_permissions(Metadata.permissions()) to be
non-destructive. While we can't guarantee this, we can at least pass
the needed info to chmod.
Also update the PermissionsExt documentation to disambiguate what it
contains, and to refer to the underlying value as `st_mode` rather than
its type `mode_t`.
Closes #44147
|
|
Fixes https://github.com/rust-lang/rust/issues/42373.
|
|
|
|
r=alexcrichton
stabilize tcpstream_connect_timeout (closes #43079)
|
|
Openoptions docs
r? @QuietMisdreavus
|
|
Clarify the behavior of UDP sockets wrt. multiple addresses in `connect`
CC @frewsxcv #22569 #44209
|
|
rustdoc: extend UdpSocket API doc (#657)
see https://github.com/carllerche/mio/issues/657
|
|
|
|
|
|
|
|
Add the libstd-modifications needed for the L4Re target
This commit adds the needed modifications to compile the std crate for the L4 Runtime environment (L4Re).
A target for the L4Re was introduced in commit: c151220a84e40b65e45308cc0f3bbea4466d3acf
In many aspects implementations for linux also apply for the L4Re microkernel.
Some uncommon characteristics had to be resolved:
* L4Re has no network funktionality
* L4Re has a maximum stacksize of 1Mb for threads
* L4Re has no uid or gid
Co-authored-by: Sebastian Humenda <sebastian.humenda@tu-dresden.de>
|
|
|
|
|
|
|
|
The default min stack size value is smaller on l4re and therefore
this value has to be different depending on the platform.
|
|
|
|
|
|
Add or_default to Entry APIs
As argued for in #44324, this PR adds a new `or_default` method to the various `Entry` APIs (currently just for `BTreeMap` and `HashMap`) when `V: Default`. This method is effectively a shorthand for `or_insert_with(Default::default)`.
|
|
|
|
|
|
rustdoc: type-fixes
|
|
kennytm:fix-44216-instance-plus-max-duration-should-panic, r=alexcrichton
Properly detect overflow in Instance ± Duration.
Fix #44216.
Fix #42622
The computation `Instant::now() + Duration::from_secs(u64::max_value())` now panics. The call `receiver.recv_timeout(Duration::from_secs(u64::max_value()))`, which involves such time addition, will also panic.
The reason #44216 arises is because of an unchecked cast from `u64` to `i64`, making the duration equivalent to -1 second.
Note that the current implementation is over-conservative, since e.g. (-2⁶²) + (2⁶³) is perfectly fine for an `i64`, yet this is rejected because (2⁶³) overflows the `i64`.
|
|
|
|
|
|
Rollup of 13 pull requests
- Successful merges: #44262, #44329, #44332, #44347, #44372, #44384, #44387, #44396, #44449, #44451, #44457, #44464, #44467
- Failed merges:
|
|
std::thread::LocalKey: Document limitation with initializers
Document that if a `LocalKey`'s initializer recursively depends on itself, initialization will result in infinite recursion.
|
|
std: Fix a segfault on OSX with backtraces
Apparently `dladdr` can succeed but still give you NULL pointers!
Closes #44379
|
|
|
|
|
|
Add libbacktrace support for Apple platforms (resubmitted)
Resubmitting #43422 rebased on the current master (cc @JohnColanduoni).
I have added an additional commit to fallback to `dladdr`-based `resolve_symbol` if `libbacktrace` returns `None`, otherwise the stack trace will be full of `<unknown>` when you forget to pass the `-g` flag (actually it seems — at least on macOS — the `dladdr` symbol is more accurate than the `libbacktrace` one).
|
|
|
|
|
|
Revert clamp
Revert clamp per https://github.com/rust-lang/rust/issues/44095#issuecomment-328218316 while we take time to assess the potential backwards compatibility damage done by it.
|
|
|
|
This reverts commit c589f867f89d4e6e48c6602aed8e878208d4822f.
|
|
This reverts commit f74c5d2e18e50c24de2cc1192bf2088cdaa61916.
|
|
This reverts commit 61f20f8df02e53ee60dc1719ce0e502eecebf8b4.
|
|
This reverts commit 576426a05a1a6cb33eece7082d7341b7c6bb5277.
|
|
This reverts commit 2e34ff767113c6a15c5862b0646ca9ad7ffd81b1.
|