Gate macOS on both Azure and GHA
As discussed in the previous infrastructure team meeting, this PR gates macOS builds on both GHA and Azure. Once this is merged we'll wait a week or two to see if there is a troublesome rate of spurious failures, and if not we'll remove the builds on the Azure side.
r? `@Mark-Simulacrum`
cc #71988
improve diagnostics for lifetime after `&mut`
If, when parsing a borrow pointee type, we see a lifetime after `mut`, suggest placing the lifetime before `mut` and eat the lifetime to avoid a large number of unhelpful diagnostics.
There are some subtleties to avoid false positives in cases like `&mut 'a + Trait`, where `&mut ('a + Trait)` is a better suggestion.
fixes#73568
On Fuchsia, spawning a subprocess does not automatically
clone all of the parent process' capabilities. UTC time on
Fuchsia is managed by a top-level userspace clock capability
that is cloned and passed to subprocesses.
This change ensures that any Rust subprocess gets access to the
UTC clock, if the parent had access to it. This is critical for
tests, which on Fuchsia, use panic=abort and spawn subprocesses
per test.
Update stdarch
This PR **changes the public signature** of the following functions in `core::arch::{x86, x86_64}`:
```patch
-pub unsafe fn _mm256_extract_epi8(a: __m256i, imm8: i32) -> i8
+pub unsafe fn _mm256_extract_epi8(a: __m256i, imm8: i32) -> i32
-pub unsafe fn _mm256_extract_epi16(a: __m256i, imm8: i32) -> i16
+pub unsafe fn _mm256_extract_epi16(a: __m256i, imm8: i32) -> i32
```
This change is desired so that these signatures
* are similar to those of the 128-bit versions `_mm_extract_epi8` and `_mm_extract_epi16`
* match the Intel definitions for the intrinsics
* [RFC 2325](https://github.com/rust-lang/rfcs/blob/master/text/2325-stable-simd.md) specifies that the exact vendor function signatures should be used
A [crater run](https://github.com/rust-lang/rust/pull/73166#issuecomment-667230319) revealed only a single breakage. The [vektor crate](https://github.com/AdamNiederer/vektor/blob/master/src/x86/avx2.rs#L2436-L2472) copied the incorrect signatures in `core` exactly to their own crate. The functions don't seem to be used by anyone anywhere.
Actual breakage is not expected, since due to the nature of the functions, users would generally write `_mm256_extract_epi8(...) as u8` or `_mm256_extract_epi16(...) as u16`.
See https://github.com/rust-lang/stdarch/pull/868/. Note that the changes from that stdarch PR have already partially landed in core after https://github.com/rust-lang/stdarch/pull/878/. This PR is now only about the remaining changes.
Implementation of peer credentials for Unix sockets
The code in `ucred.rs` is based on the work done in [PR 13](https://github.com/tokio-rs/tokio-uds/pull/13) in the tokio-uds repository on GitHub.
This commit is effectively a port to the stdlib, so credit to Martin Habovštiak (`@Kixunil)` and contributors for the meat of this work. 🥇
Happy to make changes as needed. 🙂
This allows configuring the default stage for each sub-command individually.
- Normalize the stage as early as possible, so there's no confusion
about which to use.
- Don't add an explicit `stage` option in config.toml
This offers no more flexibility than `*_stage` and makes it confusing
which takes precedence.
- Always give `--stage N` precedence over config.toml
- Fix bootstrap tests
This changes the tests to go through `Config::parse` so that they test
the actual defaults, not the dummy ones provided by `default_opts`. To
make this workable (and independent of the environment), it does not
read `config.toml` for tests.
Always try to promote shared LLVM to the sysroot
Even when LLVM is not generally participating in a shared link with rustc, we
will likely still link to the shared dylib from rust-lld, so we still need to
promote it.
This reverts part of #76349; my expectation that the link-shared rule was sufficient was likely wrong.
Hopefully fixes#76698.
r? `@alexcrichton`
Windows doesn't quite support dynamic linking to LLVM yet, but on other
platforms we do. In #76708, it was discovered that we dynamically link to LLVM
from the LLVM tools (e.g., rust-lld), so we need the shared LLVM library to link
against. That means that if we do not have a shared link to LLVM, and want LLVM
tools to work, we'd be shipping two copies of LLVM on all of these platforms:
one in librustc_driver and one in libLLVM.
Also introduce an error into rustbuild if we do end up configured for shared
linking on Windows.
Split `core::slice` to smaller mods
Unfortunately the `#[lang = "slice"]` is too big (3003 lines), I cannot split it further.
Note for reviewer:
* I split to multiple commits for easier reviewing, but I could git squash them all to one if requested.
* Recommend pulling this change locally and using advanced git diff viewer or this command:
```
git show --reverse --color-moved=dimmed-zebra master..
```
---
I split core/slice/mod.rs to these modules:
* `ascii`: For operations on `[u8]`.
* `cmp`: For comparison operations on `[T]`, like PartialEq and SliceContains impl.
* `index`: For indexing operations like Index/IndexMut and SliceIndex.
* `iter`: For Iterator definitions and implementation on `[T]`.
- `macros`: For iterator! and forward_iterator! macros.
* `raw`: For free function to create `&[T]` or `&mut [T]` from pointer + length or a reference.
The heapsort wrapper in mod.rs is removed in favor of reexport from `sort::heapsort`.
* Change error message for type param in a const expression when using
min_const_generics
* Change ParamInNonTrivialAnonConst to contain an extra bool used for
distinguishing whether the passed-in symbol is a type or a value.
Refactor intra doc link code
I got tired of `fold_item` being 500 lines long.
This is best reviewed one commit at a time with whitespace changes hidden.
There are no logic changes other than the last commit making a parameter checked by the caller instead of the callee.
r? `@Manishearth`
Optimize behavior of vec.split_off(0) (take all)
Optimization improvement to `split_off()` so the performance meets the
intuitively expected behavior when `at == 0`, avoiding the current behavior
of copying the entire vector.
The change honors documented behavior that the original vector's
"previous capacity unchanged".
This improvement better supports the pattern for building and flushing a
buffer of elements, such as the following:
```rust
let mut vec = Vec::new();
loop {
vec.push(something);
if condition_is_met {
process(vec.split_off(0));
}
}
```
`Option` wrapping is the first alternative I thought of, but is much
less obvious and more verbose:
```rust
let mut capacity = 1;
let mut vec: Option<Vec<Stuff>> = None;
loop {
vec.get_or_insert_with(|| Vec::with_capacity(capacity)).push(something);
if condition_is_met {
capacity = vec.capacity();
process(vec.take().unwrap());
}
}
```
Directly using `mem::replace()` (instead of calling`split_off()`) could work,
but `mem::replace()` is a more advanced tool for Rust developers, and in
this case, I believe developers would assume the standard library should
be sufficient for the purpose described here.
The benefit of the approach to this change is it does not change the
existing API contract, but improves the peformance of `split_off(0)` for
`Vec`, `String` (which delegates `split_off()` to `Vec`), and any other
existing use cases.
This change adds tests to validate the behavior of `split_off()` with
regard to capacity, as originally documented, and confirm that behavior
still holds, when `at == 0`.
The change is an implementation detail, and does not require a
documentation change, but documenting the new behavior as part of its
API contract may benefit future users.
(Let me know if I should make that documentation update.)
Note, for future consideration:
I think it would be helpful to introduce an additional method to `Vec`
(if not also to `String`):
```
pub fn take_all(&mut self) -> Self {
self.split_off(0)
}
```
This would make it more clear how `Vec` supports the pattern, and make
it easier to find, since the behavior is similar to other `take()`
methods in the Rust standard library.
r? `@wesleywiser`
FYI: `@tmandry`
use sort_unstable to sort primitive types
It's not important to retain original order if we have &[1, 1, 2, 3] for example.
clippy::stable_sort_primitive
Some errors, like if rustc is broken, or dylib search path is wrong,
will only display non-JSON errors. Show those, too, to make it easier to
debug a problem.
More structured suggestions for boxed trait objects instead of impl Trait on non-coerceable tail expressions
When encountering a `match` or `if` as a tail expression where the
different arms do not have the same type *and* the return type of that
`fn` is an `impl Trait`, check whether those arms can implement `Trait`
and if so, suggest using boxed trait objects.
Use structured suggestion for `impl T` to `Box<dyn T>`.
Fix https://github.com/rust-lang/rust/issues/69107
