Updates the description in the `tests/fail/tree_borrows/implicit_writes/as_mut_ptr.rs` test. The referenced file no longer exists.
Co-authored-by: Ralf Jung <post@ralfj.de>
Revert tearing changes to `dbg!`
Since the primary change to `dbg!` in rust-lang/rust#149869, we've been chasing a few regressions:
* rust-lang/rust#153850, fixed by rust-lang/rust#154074
* rust-lang/rust#154988, fixed by rust-lang/rust#154994
* rust-lang/rust#155902, proposed fix in rust-lang/rust#155915
We already reverted this once, on beta only to prevent these regressions from shipping in 1.95.
In that most recent PR, we decided that it would be better to revert `dbg!` to its original state everywhere (`main` and 1.96-`beta`), and then we can consider it from scratch later. So here I've reverted the change and its fixes, but kept the regression tests, including the pending one.
cc @joboet @dianne @rust-lang/libs
@rustbot label beta-nominated
Make bitset `would_modify_words` more vectorizer-friendly
Currently this function compares a single pair of `u64` at a time, which is potentially slower than comparing multiple words before each early-exit check, especially for the large chunks used by ChunkedBitSet.
Perf shows a notable improvement in `cranelift-codegen`, which is the one benchmark that is known to stress these code paths.
- Incorporates https://github.com/rust-lang/rust/pull/153759.
[rustdoc] Move `span_map` file to the right folder
This file should at the same level as `highlight.rs` and `macro_expansion.rs` as it doesn't do anything in `render`.
r? @yotamofek
Move tests closures
Hi, I have moved a few closures related tests. Please review them when you can find the time. This is a part of [133895](https://github.com/rust-lang/rust/issues/133895)
Add support for xray in aarch64 unknown none targets
I am currently working on an embedded project and use the target `aarch64-unknown-none`, which I want to profile.
I found the following compiler flag `-Z instrument-xray` (https://doc.rust-lang.org/unstable-book/compiler-flags/instrument-xray.html) available and I locally built a toolchain that sets the `supports_xray: true` option in `TargetOptions` for `compiler/rustc_target/src/spec/targets/aarch64_unknown_none.rs`.
Using this toolchain in `rustup` I am able to use the instrumentation pass and I verified that the disassembly looks as what I want.
I understand that it isn't available upstream while being supported due to the separate runtime library which has to be linked (e.g., https://www.llvm.org/docs/XRay.html#xray-runtime-library), which is not available for `aarch64-unknown-none`.
I argue that someone who cross-compiles for `aarch64-unknown-none` would be okay with writing a separate runtime library themselves, which I intend to do.
As far as I understood it is not necessarily required to have a runtime library at this point, i.e., the user of this API should link it, e.g., from their `build.rs` file using `cargo::rustc-link-lib=LIB` if there is an XRay LIB available for the respective target, e.g., `clang+llvm-19.1.1-aarch64-linux-gnu/lib/clang/19/lib/aarch64-unknown-linux-gnu/libclang_rt.xray-fdr.a` (which afaik there isn't for `aarch64-unknown-none`) and do "configuration as code" of XRay's options.
It should not be part of the compiler, because the instrumentation and the runtime library are completely decoupled. One can modify the instrumented code by the compiler pass however one wants to, this again pushes me into the direction of telling the developer to bring his own runtime library.
I would like to bring my change that enables this instrumentation back into upstream to facilitate my developer experience.
ci: Add dist-aarch64-freebsd
Add scripts to build the aarch64-unknown-freebsd target in CI.
Implements MCP: https://github.com/rust-lang/compiler-team/issues/961
There is currently the issue of FreeBSD version support. See the following thread for more details:
https://github.com/rust-lang/rust/pull/132228
The current version supported by rust is FreeBSD 12, which is already EOL. This means it is no longer possible to download FreeBSD releases from their servers. The aarch64 build is not mirrored on the Rust servers, which is why I couldn't match the version used by already existing CI scripts and had to change this one to FreeBSD 13. FreeBSD 13 itself will be EOL a month from now, on April 30th. We might want to put aarch64 FreeBSD builds on the Rust mirror and update the support across the board to FreeBSD 14 prior to merging this.
Privacy: try use queue instead of fixed-point iteration
Earlier: iterate until updates of `EffectiveVisibility` occur.
Now: if an update occurs, then we put in the queue those items that may be affected by this update. Iterate until there are items in the queue.
r? @petrochenkov
1. Blocking `connect`s which fail no longer only return EINPROGRESS but
instead return the correct error code.
2. Manually reading SO_ERROR outside of `ensure_connected` no longer
allows the socket to be upgraded to `Connected` despite the `connect`
failing.
3. Introduced new `ConnectionFailed` state to disallow actions on
sockets with a failed `connect`.
test new solver on CI until stabilization
We need the new solver to be able to build the stdlib, and this has regressed in the recent past. Things are broken right now, and we want to ensure this keeps working until stabilization later this year.
I've added this to the `x86_64-gnu-llvm-XX` job (note no `-1/2/3` suffix) so it's run on PR and auto CI, and because it's roughly the fastest of these builders, though maybe the aarch64 llvm 1 and 2 are slightly faster.
Building the stage 1 `./x build library/` is generally quite quick, a couple minutes at most.
The new solver fix to build std is from @lcnr [on zulip](https://rust-lang.zulipchat.com/#narrow/channel/364551-t-types.2Ftrait-system-refactor/topic/weekly.20sync.2Fupdates/near/591998234).
r? @marcoieni
Widen the result of `widening_mul`.
Tracking issue: rust-lang/rust#152016
This PR implements <https://github.com/rust-lang/rust/issues/152016#issuecomment-3843258926>, which mandates that `widening_mul` return a single, scalar value rather than a low/high tuple.
Consequently, this method is removed from `u128` and `i128` as they are the widest integral types. It has also been removed from `usize` and `isize` due to portability concerns.
Existing `widening_mul` usage has been replaced by equivalent calls to `carrying_mul` (which is logically identical to the old behaviour.) Existing – generic – non-doc tests have been removed.
# Public API
```rust
impl u8 {
pub const fn widening_mul(self, rhs: Self) -> u16;
}
impl u16 {
pub const fn widening_mul(self, rhs: Self) -> u32;
}
impl u32 {
pub const fn widening_mul(self, rhs: Self) -> u64;
}
impl u64 {
pub const fn widening_mul(self, rhs: Self) -> u128;
}
impl i8 {
pub const fn widening_mul(self, rhs: Self) -> i16;
}
impl i16 {
pub const fn widening_mul(self, rhs: Self) -> i32;
}
impl i32 {
pub const fn widening_mul(self, rhs: Self) -> i64;
}
impl i64 {
pub const fn widening_mul(self, rhs: Self) -> i128;
}
```
Add pext/pdep as aliases for extract_bits/deposit_bits
So that the methods will be found when searching for the corresponding intrinsics.
Tracking issue for `extract_bits`/`deposit_bits`: https://github.com/rust-lang/rust/issues/149069
Fix invalid suggestion for parenthesized break
Resolvesrust-lang/rust#156383
The old code incorrectly assumed `e.span` started exactly at the beginning of `break`. Fixed by locating the exact start position of `break`.
Derives `Copy` for `ffi::FromBytesUntilNulError`
[`ffi::FromBytesWithNulError` derives `Copy` since Rust 1.93](https://github.com/rust-lang/rust/commit/2f5a3d4b06a0a9e8749c2e361758ec517df0c96a) while `ffi::FromBytesUntilNulError` doesn't.
This Pr fixes that by deriving `Copy` for `ffi::FromBytesUntilNulError`.
I encountered this issue while I was working in a const context.
Note: I couldn't find any documentation about what kind of PR is allowed. As this one is very small, I guess it is ok to submit it directly without opening an issue first?
Remove `UncheckedIterator`
The only remaining usage of `UncheckedIterator` was in `array::{try_,}from_trusted_iterator`. So, replace `array::repeat` and array's `Clone` impl with a manual `from_fn` call rather than going through unnecessary abstractions, and remove the `UncheckedIterator` trait.
Allow `global_asm!` in statement positions
This PR makes it possible to put `global_asm!` in statement positions. This is particularly useful for proc-macros, where you otherwise have to wrap them in `mod foo { global_asm!(...); }`.
I'm happy to open an ACP first (or a design meeting?).
I would also assume this needs sign-off from the lang-team?
Previously discussed on [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/216763-project-inline-asm/topic/Item.20position.20global_asm/with/581784943).
r? @Amanieu
Implement `OsStr::split_at`
See rust-lang/rust#156199
This allows splitting only on valid UTF-8 boundaries, regardless of the platform, which avoids cross-platform landmines.
Ralf Jung