Retain suid/sgid/sticky bits in Metadata.permissions
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
Correctly bubble up errors from libbacktrace
Previously the first part of this code didn't check for a null pointer and blindly passed it back down, causing a segfault if libbacktrace failed to initialise. I've changed this to check and bubble up the error if relevant.
Suggested diff view: https://github.com/rust-lang/rust/pull/44525/files?w=1
hide internal types/traits from std docs via new #[doc(masked)] attribute
Fixes#43701 (hopefully for good this time)
This PR introduces a new parameter to the `#[doc]` attribute that rustdoc looks for on `extern crate` statements. When it sees `#[doc(masked)]` on such a statement, it hides traits and types from that crate from appearing in either the "Trait Implementations" section of many type pages, or the "Implementors" section of trait pages. This is then applied to the `libc`/`rand`/`compiler_builtins` imports in libstd to prevent those crates from creating broken links in the std docs.
Like in #43348, this also introduces a feature gate, `doc_masked`, that controls the use of this parameter.
To view the std docs generated with this change, head to https://tonberry.quietmisdreavus.net/std-43701/std/index.html.
Document thread builder panics for nul bytes in thread names
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.
Add Cow<str> -> Box<Error> impls.
Considering how impls exist for `String` and `&str`, it makes sense to also add an impl for `Cow<str>` as well.
This would allow converting `String::from_utf8_lossy` directly into a `Box<Error>` or `io::Error` without having to add an extra `into_ownd()`.
Ensure tcp test case passes when disconnected from network
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
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`
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
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: c151220a84
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>
