| Age | Commit message (Collapse) | Author | Lines |
|---|
|
r=tgross35,RalfJung,WaffleLapkin
Initial `UnsafePinned` implementation [Part 1: Libs]
Initial libs changes necessary to unblock further work on [RFC 3467](https://rust-lang.github.io/rfcs/3467-unsafe-pinned.html).
Tracking issue: #125735
This PR is split off from #136964, and includes just the libs changes:
- `UnsafePinned` struct
- private `UnsafeUnpin` structural auto trait
- Lang items for both
- Compiler changes necessary to block niches on `UnsafePinned`
This PR does not change codegen, miri, the existing `!Unpin` hack, or anything else. That work is to be split into later PRs.
---
cc ``@RalfJung`` ``@Noratrieb``
``@rustbot`` label F-unsafe_pinned T-libs-api
|
|
Rollup of 10 pull requests
Successful merges:
- #138972 (std: Fix build for NuttX targets)
- #139177 (Use -C target-cpu=z13 on s390x vector test)
- #139511 (libtest: Pass the test's panic payload as Option instead of Result)
- #139605 (update ```miniz_oxide``` to 0.8.8)
- #139618 (compiletest: Make `SUGGESTION` annotations viral)
- #139677 (Fix profiler_builtins build script to handle full path to profiler lib)
- #139683 (Use `with_native_path` for Windows)
- #139710 (Move `args` into `std::sys`)
- #139721 (End all lines in src/stage0 with trailing newline)
- #139726 (Move `select_unpredictable` to the `hint` module)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Move `select_unpredictable` to the `hint` module
There has been considerable discussion in both the ACP (rust-lang/libs-team#468) and tracking issue (#133962) about whether the `bool::select_unpredictable` method should be in `core::hint` instead.
I believe this is the right move for the following reasons:
- The documentation explicitly says that it is a hint, not a codegen guarantee.
- `bool` doesn't have a corresponding `select` method, and I don't think we should be adding one.
- This shouldn't be something that people reach for with auto-completion unless they specifically understand the interactions with branch prediction. Using conditional moves can easily make code *slower* by preventing the CPU from speculating past the condition due to the data dependency.
- Although currently `core::hint` only contains no-ops, this isn't a hard rule (for example `unreachable_unchecked` is a bit of a gray area). The documentation only status that the module contains "hints to compiler that affects how code should be emitted or optimized". This is consistent with what `select_unpredictable` does.
|
|
compiletest: Make `SUGGESTION` annotations viral
If one of them is expected in a test file, then others should be annotated as well, in the same way as with `HELP`s and `NOTE`s.
This doesn't require much of an additional annotation burden, but simplifies the rules.
r? ```@jieyouxu```
|
|
Use -C target-cpu=z13 on s390x vector test
currently we see a regression in the `dont-shuffle-bswaps.rs` on s390x. This is due to, the default s390x cpu is set to z10 [here](https://github.com/rust-lang/rust/blob/master/compiler/rustc_target/src/spec/targets/s390x_unknown_linux_gnu.rs#L9) which does not have vector instructions implemented. To make the test pass we need to create an extra test revision and set target-cpu at least to `z13`.
|
|
Use the chaining methods on PartialOrd for slices too
#138135 added these doc-hidden trait methods to improve the tuple codegen. This PR adds more implementations and callers so that the codegen for slice (and array) comparisons also improves.
|
|
Rollup of 6 pull requests
Successful merges:
- #139107 (std: make `cmath` functions safe)
- #139607 (Add regression test for #127424)
- #139691 (Document that `opt-dist` requires metrics to be enabled)
- #139707 (Fix comment in bootstrap)
- #139708 (Fix name of field in doc comment)
- #139709 (bootstrap: fix typo in doc string)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
Add regression test for #127424
Fixes: https://github.com/rust-lang/rust/issues/127424
This ICE no longer reproduces, so it appears to have already been fixed.
This PR adds a regression test to ensure the issue doesn’t come back in the future.
Please let me know if there's anything I should improve or revise!
|
|
|
|
Removed outdated ui test suite README, give reasons for disabled tests
### Changes
- `tests/ui/README.md` is very outdated, test suite docs should consistently live in rustc-dev-guide.
- Add reasons for `//@ ignore-test` tests that don't have one.[^query]
This is a precursor change to make follow-up changes easier (possibly more specialized directives or converting some auxiliaries into the canonical `auxiliary/` form).
[^query]: searched via `rg --no-ignore -F -e "ignore-test" tests/`.
|
|
rustdoc-search: add unbox flag to Result aliases
Fixes #139665
|
|
run-make-support: Calculate artifact names for target platform, not host platform
This was implemented incorrectly during the porting process, where we relied on std consts. However, `run-make-support` is a host-only library, which meant that these artifact names were for the *host* and not the *target*.
Helps with #138066.
r? `@Kobzol`
try-job: armhf-gnu
try-job: test-various
try-job: x86_64-msvc-1
try-job: i686-msvc-1
try-job: x86_64-mingw-1
try-job: aarch64-apple
try-job: x86_64-apple-1
|
|
|
|
|
|
We should consolidate our test suite docs in rustc-dev-guide, and this
README is very outdated.
|
|
Some tests fail on cross-compiled targets due to various linker problems
on cross-compiled target, and having test coverage for these against
cross-compiled targets is nice but not necessary.
|
|
Polymorphize `array::IntoIter`'s iterator impl
Today we emit all the iterator methods for every different array width. That's wasteful since the actual array length never even comes into it -- the indices used are from the separate `alive: IndexRange` field, not even the `N` const param.
This PR switches things so that an `array::IntoIter<T, N>` stores a `PolymorphicIter<[MaybeUninit<T>; N]>`, which we *unsize* to `PolymorphicIter<[MaybeUninit<T>]>` and call methods on that non-`Sized` type for all the iterator methods.
That also necessarily makes the layout consistent between the different lengths of arrays, because of the unsizing. Compare that to today <https://rust.godbolt.org/z/Prb4xMPrb>, where different widths can't even be deduped because the offset to the indices is different for different array widths.
|
|
Tweak `DefPathData`
Some improvements in and around `DefPathData`, following on from #137977.
r? `@spastorino`
|
|
Handle a negated literal in `eat_token_lit`.
Fixes #139495.
r? `@petrochenkov`
|
|
Use `BinOp::Cmp` for `iNN::signum`
This way it can use the nice new LLVM intrinsic in LLVM20.
|
|
Fixes #139665
|
|
Prepend temp files with per-invocation random string to avoid temp filename conflicts
https://github.com/rust-lang/rust/issues/139407 uncovered a very subtle unsoundness with incremental codegen, failing compilation sessions (due to assembler errors), and the "prefer hard linking over copying files" strategy we use in the compiler for file management.
Specifically, imagine we're building a single file 3 times, all with `-Csave-temps -Cincremental=...`. Let's call the object file we're building for the codegen unit for `main` "`XXX.o`" just for clarity since it's probably some gigantic hash name:
```
#[inline(never)]
#[cfg(any(rpass1, rpass3))]
fn a() -> i32 {
0
}
#[cfg(any(cfail2))]
fn a() -> i32 {
1
}
fn main() {
evil::evil();
assert_eq!(a(), 0);
}
mod evil {
#[cfg(any(rpass1, rpass3))]
pub fn evil() {
unsafe {
std::arch::asm!("/* */");
}
}
#[cfg(any(cfail2))]
pub fn evil() {
unsafe {
std::arch::asm!("missing");
}
}
}
```
Session 1 (`rpass1`):
* Type-check, borrow-check, etc.
* Serialize the dep graph to the incremental working directory `.../s-...-working/`.
* Codegen object file to a temp file `XXX.rcgu.o` which is spit out in the cwd.
* Hard-link[^1] `XXX.rcgu.o` to the incremental working directory `.../s-...-working/XXX.o`.
* Save-temps option means we don't delete `XXX.rgcu.o`.
* Link the binary and stuff.
* Finalize[^2] the working incremental session by renaming `.../s-...-working` to ` s-...-asjkdhsjakd` (some other finalized incr comp session dir name).
Session 2 (`cfail2`):
* Load artifacts from the previous *finalized* incremental session, namely the dep graph.
* Type-check, borrow-check, etc. since the file has changed, so most dep graph nodes are red.
* Serialize the dep graph to the incremental working directory `.../s-...-working/`.
* Codegen object file to a temp file `XXX.rcgu.o`. **HERE IS THE PROBLEM**: The hard-link is still set up to point to the inode from `XXX.o` from the first session, so this also modifies the `XXX.o` in the previous finalized session directory.
* Codegen emits an error b/c `missing` is not an instruction, so we abort before finalizing the incremental session. Specifically, this means that the *previous* session is the last finalized session.
Session 3 (`rpass3`):
* Load artifacts from the previous *finalized* incremental session, namely the dep graph. NOTE that this is from session 1.
* All the dep graph nodes are green since we are basically replaying session 1.
* codegen object file `XXX.o`, which is detected as *reused* from session 1 since dep nodes were green. That means we **reuse** `XXX.o` which had been dirtied from session 2.
* Link the binary and stuff.
This results in a binary which reuses some of the build artifacts from session 2, but thinks it's from session 1.
At this point, I hope it's clear to see that the incremental results from session 1 were dirtied from session 2, but we reuse them as if session 1 was the previous (finalized) incremental session we ran. This is at best really buggy, and at worst **unsound**.
This isn't limited to `-C save-temps`, since there are other combinations of flags that may keep around temporary files (hard linked) in the working directory (like `-C debuginfo=1 -C split-debuginfo=unpacked` on darwin, for example).
---
This PR implements a fix which is to prepend temp filenames with a random string that is generated per invocation of rustc. This string is not *deterministic*, but temporary files are transient anyways, so I don't believe this is a problem.
That means that temp files are now something like... `{crate-name}.{cgu}.{invocation_temp}.rcgu.o`, where `{invocation_temp}` is the new temporary string we generate per invocation of rustc.
Fixes https://github.com/rust-lang/rust/issues/139407
[^1]: https://github.com/rust-lang/rust/blob/175dcc7773d65c1b1542c351392080f48c05799f/compiler/rustc_fs_util/src/lib.rs#L60
[^2]: https://github.com/rust-lang/rust/blob/175dcc7773d65c1b1542c351392080f48c05799f/compiler/rustc_incremental/src/persist/fs.rs#L1-L40
|
|
Fix breakage when running compiletest with `--test-args=--edition=2015`
Compiletest has an `--edition` flag to change the default edition tests are run with. Unfortunately no test suite successfully executes when that flag is passed. If the edition is set to something greater than 2015 the breakage is expected, since the test suite currently supports only edition 2015 (Ferrous Systems will open an MCP about fixing that soonish). Surprisingly, the test suite is also broken if `--edition=2015` is passed to compiletest. This PR focuses on fixing the latter.
This PR fixes the two categories of failures happening when `--edition=2015` is passed:
* Some edition-specific tests set their edition through `//@ compile-flags` instead of `//@ edition`. Compiletest doesn't parse the compile flags, so it would see no `//@ edition` and add another `--edition` flag, leading to a rustc error.
* Compiletest would add the edition after `//@ compile-flags`, while some tests depend on flags passed to `//@ compile-flags` being the last flags in the rustc invocation.
Note that for the first category, I opted to manually go and replace all `//@ compile-flags` setting an edition with an explicit `//@ edition`. We could've changed compiletest to instead check whether an edition was set in `//@ compile-flags`, but I thought it was better to enforce a consistent way to set the edition in tests.
I also added the edition to the stamp, so that changing `--edition` results in tests being re-executed.
r? `@jieyouxu`
|
|
Give them their own symbol `anon_assoc`, as is done for all the other
anonymous `DefPathData` variants.
|
|
|
|
Improve `AssocItem::descr`.
The commit adds "associated" to the description of associated types and associated consts, to match the description of associated functions. This increases error message precision and consistency with `AssocKind::fmt`.
The commit also notes an imperfection in `AssocKind::fmt`; fixing this imperfection is possible but beyond the scope of this PR.
r? `@estebank`
|
|
r=compiler-errors
Allow parenthesis around inferred array lengths
In #135272 it was noticed that we weren't handling `Vec<(((((_)))))>` correctly under the new desugaring for `generic_arg_infer`, this had to be fixed in order to not regress stable code for types that should continue working. This has the side effect of *also* allowing the following to work:
```rust
#![feature(generic_arg_infer)]
struct Bar<const N: usize>;
fn main() {
let a: Bar<((_))> = Bar::<10>;
}
```
However I did not make the same change for array lengths resulting in the following not compiling:
```rust
#![feature(generic_arg_infer)]
fn main() {
let a: [u8; (((_)))] = [2; 2];
let a: [u8; 2] = [2; (((((_)))))];
}
```
This is rather inconsistent as parenthesis around `_` *are* supported for const args to non-arrays, and type args. This PR fixes this allowing the above example to compile. No stable impact.
r? compiler-errors
|
|
Deeply normalize obligations in `BestObligation` folder
Built on #139513.
This establishes a somewhat rough invariant that the `Obligation`'s predicate is always deeply normalized in the folder; when we construct a new obligation we normalize it.
Putting this up for discussion since it does affect some goals.
r? lcnr
|
|
Introduce a `//@ needs-crate-type` compiletest directive
The `//@ needs-crate-type: $crate_types...` directive takes a comma-separated list of crate types that the target platform must support in order for the test to be run. This allows the test writer to semantically convey that the ignore condition is based on target crate type needs, instead of using a general purpose `//@ ignore-$target` directive (often without comment).
Fixes #132309.
### Example
```rs
//@ needs-crate-type: dylib (ignored on e.g. wasm32-unknown-unknown)
//@ compile-flags: --crate-type=dylib
fn foo() {}
```
### Review advice
- Best reviewed commit-by-commit.
- The impl is not very clean, I briefly attempted to clean up the directive handling but found that more invasive changes are needed, so I'd like to not block on the cleanup for now.
try-job: test-various
try-job: armhf-gnu
|
|
rperier:donot_suggest_to_use_impl_trait_in_closure_params, r=Noratrieb
Don't suggest the use of `impl Trait` in closure parameter
Fixes #138932
|
|
Test linking and running `no_std` binaries
I looked around, but it seems that we do not have a test that tests a `#![no_std]` + `#![no_main]` binary. So now I've added one. Motivated by discussion in [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/Provide.20.60__isPlatformVersionAtLeast.60.20in.20.60std.60.3F/with/507870028).
r? ```@tgross35```
try-job: arm-android
try-job: armhf-gnu
try-job: dist-ohos
try-job: x86_64-mingw-1
|
|
Allow drivers to supply a list of extra symbols to intern
Allows adding new symbols as `const`s in external drivers, desirable in Clippy so we can use them in patterns to replace code like https://github.com/rust-lang/rust/blob/75530e9f72a1990ed2305e16fd51d02f47048f12/src/tools/clippy/clippy_lints/src/casts/cast_ptr_alignment.rs#L66
The Clippy change adds a couple symbols as a demo, the exact `clippy_utils` API and replacing other usages can be done on the Clippy side to minimise sync conflicts
---
try-job: aarch64-gnu
|
|
rustc_target: update x86_win64 to match the documented calling convention for f128
llvm/llvm-project@5ee1c0b7148571ed9d60e447b66fb0f35de14576 updates llvm to match the documented calling convention to pass f128 indirectly. This change makes us do that on all versions of LLVM, not just starting with LLVM 21.
`@rustbot` label llvm-main
try-job: dist-x86_64-msvc
try-job: dist-x86_64-mingw
try-job: x86_64-msvc-1
try-job: x86_64-msvc-2
try-job: x86_64-mingw-1
try-job: x86_64-mingw-2
|
|
add `core::intrinsics::simd::{simd_extract_dyn, simd_insert_dyn}`
fixes https://github.com/rust-lang/rust/issues/137372
adds `core::intrinsics::simd::{simd_extract_dyn, simd_insert_dyn}`, which contrary to their non-dyn counterparts allow a non-const index. Many platforms (but notably not x86_64 or aarch64) have dedicated instructions for this operation, which stdarch can emit with this change.
Future work is to also make the `Index` operation on the `Simd` type emit this operation, but the intrinsic can't be used directly. We'll need some MIR shenanigans for that.
r? `@ghost`
|
|
The commit adds "associated" to the description of associated types and
associated consts, to match the description of associated functions.
This increases error message precision and consistency with
`AssocKind::fmt`.
The commit also notes an imperfection in `AssocKind::fmt`; fixing this
imperfection is possible but beyond the scope of this PR.
|
|
Fixes #139495.
|
|
|
|
|
|
Ensure `swap_nonoverlapping` is really always untyped
This replaces #134954, which was arguably overcomplicated.
## Fixes #134713
Actually using the type passed to `ptr::swap_nonoverlapping` for anything other than its size + align turns out to not work, so this goes back to always erasing the types down to just bytes.
(Except in `const`, which keeps doing the same thing as before to preserve `@RalfJung's` fix from #134689)
## Fixes #134946
I'd previously moved the swapping to use auto-vectorization *on bytes*, but someone pointed out on Discord that the tail loop handling from that left a whole bunch of byte-by-byte swapping around. This goes back to manual tail handling to avoid that, then still triggers auto-vectorization on pointer-width values. (So you'll see `<4 x i64>` on `x86-64-v3` for example.)
|
|
llvm/llvm-project@5ee1c0b7148571ed9d60e447b66fb0f35de14576 updates llvm
to match the documented calling convention to pass f128 indirectly.
@rustbot label llvm-main
|
|
|
|
|
|
|
|
Remove unnecessary `mut` in test.
The value is moved in `pin!()`, so the binding doesn't need to be `mut` itself.
(Rustc doesn't warn about this due to the current hacky implementation of `pin!()`. That is fixed by https://github.com/rust-lang/rust/pull/139114.)
|
|
Avoid empty identifiers for delegate params and args.
Details in individual commits.
r? `@oli-obk`
|
|
Rename some `name` variables as `ident`.
It bugs me when variables of type `Ident` are called `name`. It leads to silly things like `name.name`. `Ident` variables should be called `ident`, and `name` should be used for variables of type `Symbol`.
This commit improves things by by doing `s/name/ident/` on a bunch of `Ident` variables. Not all of them, but a decent chunk.
r? `@fee1-dead`
|
|
fix "still mutable" ice while metrics are enabled
Resolves "still mutable" ICE discovered by `@matthiaskrgr` here: [#t-docs-rs > metrics intitiative @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/356853-t-docs-rs/topic/metrics.20intitiative/near/510490790)
This was caused by invoking `crate_hash` before the `definitions` struct was frozen here: https://github.com/rust-lang/rust/blob/e643f59f6da3a84f43e75dea99afaa5b041ea6bf/compiler/rustc_interface/src/passes.rs#L951
resolved by moving metrics dumping to occur after `analysis` freezes the definitions
I'm guessing we didn't discover this in CI because the problem only occurs when you try to calculate the crash hash with incremental compilation enabled when it tries to freeze the definitions here: https://github.com/rust-lang/rust/blob/e643f59f6da3a84f43e75dea99afaa5b041ea6bf/compiler/rustc_middle/src/hir/map.rs#L1172
my understanding is that this causes us to freeze the definitions too early in compilation, then we subsequently try to mutate them, likely during `analysis`, and this causes the ICE.
r? `@bjorn3`
|
|
|
