Remove a mention to `copy_from_slice` from `clone_from_slice` doc
Fixes#84736
I think removing it would be the best but I'm happy to clarify it instead if someone would like.
Make `llvm.download-ci-llvm="if-available"` work for tier 2 targets with host tools
`llvm.download-ci-llvm="if-available"` is used for most profiles configured via `x.py setup`. It allows downloading prebuilt LLVM tarballs from the CI artifacts for a configured list of platforms. Currently this list is restricted to tier 1 targets but it makes sense for all tier 2 targets with host tools.
ty::pretty: prevent infinite recursion for `extern crate` paths.
Fixes#55779, fixes#87932.
This fix is based on `@estebank's` idea in https://github.com/rust-lang/rust/issues/55779#issuecomment-614758510 - but instead of trying to get `try_print_visible_def_path_recur`'s cycle detection to work in this case, this PR "just" disables the "visible path" feature when printing the path to an `extern crate`, so that the old recursion chain of `try_print_visible_def_path -> print_def_path -> try_print_visible_def_path`, is now impossible.
Both tests have been confirmed to crash `rustc` because of a stack overflow, without the fix.
polymorphization: shims and predicates
Supersedes #75737 and #75414. This pull request includes up some changes to polymorphization which hadn't landed previously and gets stage2 bootstrapping and the test suite passing when polymorphization is enabled. There are still issues with `type_id` and polymorphization to investigate but this should get polymorphization in a reasonable state to work on.
- #75737 and #75414 both worked but were blocked on having the rest of the test suite pass (with polymorphization enabled) with and without the PRs. It makes more sense to just land these so that the changes are in.
- #75737's changes remove the restriction of `InstanceDef::Item` on polymorphization, so that shims can now be polymorphized. This won't have much of an effect until polymorphization's analysis is more advanced, but it doesn't hurt.
- #75414's changes remove all logic which marks parameters as used based on their presence in predicates - given #75675, this will enable more polymorphization and avoid the symbol clashes that predicate logic previously sidestepped.
- Polymorphization now explicitly checks (and skips) foreign items, this is necessary for stage2 bootstrapping to work when polymorphization is enabled.
- The conditional determining the emission of a note adding context to a post-monomorphization error has been modified. Polymorphization results in `optimized_mir` running for shims during collection where that wouldn't happen previously, some errors are emitted during `optimized_mir` and these were considered post-monomorphization errors with the existing logic (more errors and shims have a `DefId` coming from the std crate, not the local crate), adding a note that resulted in tests failing. It isn't particularly feasible to change where polymorphization runs or prevent it from using `optimized_mir`, so it seemed more reasonable to not change the conditional.
- `characteristic_def_id_of_type` was being invoked during partitioning for self types of impl blocks which had projections that depended on the value of unused generic parameters of a function - this caused a ICE in a debuginfo test. If partitioning is enabled and the instance needs substitution then this is skipped. That test still fails for me locally, but not with an ICE, but it fails in a fresh checkout too, so 🤷♂️.
r? `@lcnr`
linux/aarch64 Now() should be actually_monotonic()
While issues have been seen on arm64 platforms the Arm architecture requires
that the counter monotonically increases and that it must provide a uniform
view of system time (e.g. it must not be possible for a core to receive a
message from another core with a time stamp and observe time going backwards
(ARM DDI 0487G.b D11.1.2). While there have been a few 64bit SoCs that have
bugs (#49281, #56940) which cause time to not monotonically increase, these have
been fixed in the Linux kernel and we shouldn't penalize all Arm SoCs for those
who refuse to update their kernels:
SUN50I_ERRATUM_UNKNOWN1 - Allwinner A64 / Pine A64 - fixed in 5.1
FSL_ERRATUM_A008585 - Freescale LS2080A/LS1043A - fixed in 4.10
HISILICON_ERRATUM_161010101 - Hisilicon 1610 - fixed in 4.11
ARM64_ERRATUM_858921 - Cortex A73 - fixed in 4.12
255a3f3e183 std: Force `Instant::now()` to be monotonic added a Mutex to work around
this problem and a small test program using glommio shows the majority of time spent
acquiring and releasing this Mutex. 3914a7b0da8 tries to improve this, but actually
makes it worse on big systems as for 128b atomics a ldxp/stxp pair (and successful loop)
for v8.4 systems that don't support FEAT_LSE2 is required which is expensive as a lock
and because of how the load/store-exclusives scale on large Arm systems is both unfair
to threads and tends to go backwards in performance.
A small sample program using glommio improves by 70x on a 32 core Graviton2
system with this change.
Rollup of 7 pull requests
Successful merges:
- #89507 (Add `#[repr(i8)]` to `Ordering`)
- #89849 (CI: Selecting the Xcode version no longer needed with the macos-11 runners.)
- #89886 (Update the wasi-libc built with the wasm32-wasi target)
- #89907 (Remove FIXME since there is nothing to be fixed)
- #89943 (clippy::complexity fixes)
- #89953 (Make Option::as_mut const)
- #89958 (Correct small typo)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Remove FIXME since there is nothing to be fixed
Resolves#88593.
The errors are deduplicated when displayed to users. They only appear
multiple times in UI tests.
cc ``@jyn514``
r? ``@camelid``
Update the wasi-libc built with the wasm32-wasi target
This commit updates the wasi-libc that we include with the wasm32-wasi
target, which brings in various misc fixes such as musl updates and some
math tweaks.
CI: Selecting the Xcode version no longer needed with the macos-11 runners.
It does nothing nowadays since `/Applications/Xcode_12.2.app` does not exist in the GH runner environment and
automatically using the latest version selected by the GH environment is better anyway.
Add `#[repr(i8)]` to `Ordering`
Followup to #89491 to allow `Ordering` to auto-derive `AsRepr` once the proposal to add `AsRepr` (#81642) lands.
cc ``@joshtriplett``
Remove trailing semicolon from macro call span
Macro call site spans are now less surprising/more consistent since they no longer contain a semicolon after the macro call.
The downside is that we need to do a little guesswork to get the semicolon in diagnostics. But this should not be noticeable since it is rare for the semicolon to not immediately follow the macro call.
updating docs to mention usage of AtomicBool
Mouse mentioned we should point out that atomic bool is used by the std lib these days. ( https://github.com/m-ou-se/getrandom/pull/1 )
[fuchsia] Update process info struct
The fuchsia platform is in the process of softly transitioning over to
using a new value for ZX_INFO_PROCESS with a new corresponding struct.
This change migrates libstd.
See [fxrev.dev/510478](https://fxrev.dev/510478) and [fxbug.dev/30751](https://fxbug.dev/30751) for more detail.
emitter: current substitution can be multi-line
Fixes#89280.
In `splice_lines`, there is some arithmetic to compute the required alignment such that future substitutions in a suggestion are aligned correctly. However, this assumed that the current substitution's span was only on a single line. In circumstances where this was not true, it could result in a arithmetic overflow when the substitution's end column was less than the substitution's start column.
r? ````@oli-obk````
Restrict the aarch64 outline atomics test to Linux
The test was introduced in #83655, which enables the `outline-atomics` feature for aarch64-unknown-linux-* but not for any other aarch64 targets. The test did not check for Linux causing test failures on aarch64-apple-darwin.
r? `@workingjubilee`
Stabilize `unreachable_unchecked` as `const fn`
Closes#53188
This PR stabilizes `core::hint::unreachable_unchecked` as `const fn`. MIRI is able to detect when this method is called. Stabilization was delayed until `const_panic` was stabilized so as to avoid users calling this method in its place (thus resulting in runtime UB). With #89508, that is no longer an issue.
````@rustbot```` label +A-const-eval +A-const-fn +T-lang +S-blocked
(not sure why it's T-lang, but that's what the tracking issue is)
Add abstract namespace support for Unix domain sockets
Hello! The other day I wanted to mess around with UDS in Rust and found that abstract namespaces ([unix(7)](https://man7.org/linux/man-pages/man7/unix.7.html)) on Linux still needed development. I took the approach of adding `_addr` specific public functions to reduce conflicts.
Feature name: `unix_socket_abstract`
Tracking issue: #85410
Further context: #42048
## Non-platform specific additions
`UnixListener::bind_addr(&SocketAddr) -> Result<UnixListener>`
`UnixStream::connect_addr(&SocketAddr) -> Result<()>`
`UnixDatagram::bind_addr(&SocketAddr) -> Result<UnixDatagram>`
`UnixDatagram::connect_addr(&SocketAddr) -> Result<()>`
`UnixDatagram::send_to_addr(&self, &[u8], &SocketAddr) -> Result<usize>`
## Platform-specific (Linux) additions
`SocketAddr::from_abstract_namespace(&[u8]) -> SocketAddr`
`SockerAddr::as_abstract_namespace() -> Option<&[u8]>`
## Example
```rust
#![feature(unix_socket_abstract)]
use std::os::unix::net::{UnixListener, SocketAddr};
fn main() -> std::io::Result<()> {
let addr = SocketAddr::from_abstract_namespace(b"namespace")?; // Linux only
let listener = match UnixListener::bind_addr(&addr) {
Ok(sock) => sock,
Err(err) => {
println!("Couldn't bind: {:?}", err);
return Err(err);
}
};
Ok(())
}
```
## Further Details
The main inspiration for the implementation came from the [nix-rust](https://github.com/nix-rust/nix/blob/master/src/sys/socket/addr.rs#L558) crate but there are also other [historical](c4db0685b1) [attempts](https://github.com/tormol/uds/blob/master/src/addr.rs#L324) with similar approaches.
A comment I did have was with this change, we now allow a `SocketAddr` to be constructed explicitly rather than just used almost as a handle for the return of `peer_addr` and `local_addr`. We could consider adding other explicit constructors (e.g. `SocketAddr::from_pathname`, `SockerAddr::from_unnamed`).
Cheers!
Use BCryptGenRandom instead of RtlGenRandom on Windows.
This removes usage of RtlGenRandom on Windows, in favour of BCryptGenRandom.
BCryptGenRandom isn't available on XP, but we dropped XP support a while ago.
The fuchsia platform is in the process of softly transitioning over to
using a new value for ZX_INFO_PROCESS with a new corresponding struct.
This change migrates libstd.
See fxrev.dev/510478 and fxbug.dev/30751 for more detail.
Avoid allocations and copying in Vec::leak
The [`Vec::leak`] method (#62195) is currently implemented by calling `Vec::into_boxed_slice` and `Box::leak`. This shrinks the vector before leaking it, which potentially causes a reallocation and copies the vector's contents.
By avoiding the conversion to `Box`, we can instead leak the vector without any expensive operations, just by returning a slice reference and forgetting the `Vec`. Users who *want* to shrink the vector first can still do so by calling `shrink_to_fit` explicitly.
**Note:** This could break code that uses `Box::from_raw` to “un-leak” the slice returned by `Vec::leak`. However, the `Vec::leak` docs explicitly forbid this, so such code is already incorrect.
[`Vec::leak`]: https://doc.rust-lang.org/stable/std/vec/struct.Vec.html#method.leak
In `splice_lines`, there is some arithmetic to compute the required
alignment such that future substitutions in a suggestion are aligned
correctly. However, this assumed that the current substitution's span
was only on a single line. In circumstances where this was not true, it
could result in a arithmetic overflow when the substitution's end
column was less than the substitution's start column.
Signed-off-by: David Wood <david.wood@huawei.com>
Optimize VecDeque::append
Optimize `VecDeque::append` to do unsafe copy rather than iterating through each element.
On my `Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz`, the benchmark shows 37% improvements:
```
Master:
custom-bench vec_deque_append 583164 ns/iter
custom-bench vec_deque_append 550040 ns/iter
Patched:
custom-bench vec_deque_append 349204 ns/iter
custom-bench vec_deque_append 368164 ns/iter
```
Additional notes on the context: this is the third attempt to implement a non-trivial version of `VecDeque::append`, the last two are reverted due to unsoundness or regression, see:
- https://github.com/rust-lang/rust/pull/52553, reverted in https://github.com/rust-lang/rust/pull/53571
- https://github.com/rust-lang/rust/pull/53564, reverted in https://github.com/rust-lang/rust/pull/54851
Both cases are covered by existing tests.
Signed-off-by: tabokie <xy.tao@outlook.com>
