Move some ui tests
> [!NOTE]
> I split the commits to make the review easier and to keep the git history easier to trace.
Renamed issue-xxx tests
`tests/ui/dyn-drop` -> `tests/ui/dyn-keyword`
`tests/ui/missing-trait-bounds` -> `tests/ui/trait-bound/missing-trait-bounds`
`tests/ui/recursion_limit` -> `tests/ui/recursion/recursion_limit`
`tests/ui/version` -> `tests/ui/compile-flags`
Reorganize `tests/ui/empty`
tweak r-a default settings
1. Explain that you need to make paths absolute in helix settings
2. Use the correct compiler (set `RUSTC` and `CARGO` to stage0, instead of `RUSTUP_TOOLCHAIN=nightly`)
3. Add comments to vscode and zed settings
NB: I only tested helix settings, but am pretty sure that the other changes shouldn't break anything.
tools: remote-test-server: Add UEFI run support
Tested with OVMF on QEMU with Linux as the host running remote-test-client. The instructions for running tests are provided below:
1. Use rust-lld linker: `bootstrap.toml`
```toml
[rust]
lld = true
[target.x86_64-unknown-uefi]
linker = "rust-lld"
```
2. Use a custom startup.nsh script to auto-launch remote-test-server. This is optional.
```shell
fs1:
run.efi --sequential --bind "10.0.2.15:12345" --batch
```
3. Launch remote-test-server in QEMU. I am using uefi-run script [0].
```shell
uefi-run build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-uefi/release/remote-test-server.efi -n --startup startup.nsh --tcp-port 12345
```
4. Run tests:
```shell
RUST_TEST_THREADS=1 TEST_DEVICE_ADDR="localhost:12345" ./x.py test tests/ui/abi --target x86_64-unknown-uefi --stage 1
```
Requires: https://github.com/rust-lang/rust/pull/151014
@rustbot label +O-UEFI
cc @nicholasbishop
[0]: https://github.com/Ayush1325/dotfiles/blob/2d13056bf8ca1931a234b72967d9e857c4afbf1a/uefi/.local/bin/uefi-run
std: organise `sys::pal::os`
Continuing rust-lang/rust#153341, this moves around some functions in `sys::pal`, so that `pal::os` only contains standard-path-related code (which I'll move later as part of rust-lang/rust#117276).
Best reviewed commit-by-commit.
tests: codegen-llvm: iter-repeat-n-trivial-drop: Allow non-zero lower bound to __rust_alloc size
LLVM emits a lower bound of 8 for the size parameter to `__rust_alloc` when targeting `x86_64-unknown-hermit`. Since that is also completely valid, relax the lower bound check.
I'm not really sure why LLVM is able to infer this - with the same setup targeting `x86_64-unknown-linux-gnu` I also see the lower bound of 0. Not that it's wrong, but I'd be curious to know which codegen options play into this.
* Move dyn-drop to dyn-keyword
* Reorganize `tests/ui/empty` into specific dirs
remove tests/ui/empty/empty-linkname.rs duplicate of tests/ui/error-codes/E0454.rs
* Move `missing-trait-bounds` to `trait-bound/missing-trait-bounds`
* bless traits/missing-trait-bounds tests
* Move `recursion_limit` to `recursion/recursion_limit`
* Move `version` to `compile-flags`
Enable link relaxation feature for LoongArch Linux targets
This patch series enables the link relaxation feature for LoongArch Linux targets. Link relaxation is a link-time optimization that helps improve the quality and efficiency of the final binary. To support this, the corss-toolchain has also been bumped to handle more types of link relaxation.
core: respect precision in `ByteStr` `Display`
Fixesrust-lang/rust#153022.
`ByteStr`'s `Display` implementation didn't respect the precision parameter. Just like `Formatter::pad`, this is fixed by counting off the characters in the string and truncating after the requested length – with the added complication that the `ByteStr` needs to be divided into chunks first. By including a fast path that avoids counting the characters when no parameters were specified this should also fix the performance regressions caused by rust-lang/rust#152865.
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#152535 (std: use `OnceLock` for Xous environment variables)
- rust-lang/rust#152646 (Update `UnsafeUnpin` impls involving extern types.)
- rust-lang/rust#153559 (Inline and simplify some code for saving incremental data to disk)
- rust-lang/rust#151900 (num: Separate public API from internal implementations)
- rust-lang/rust#153520 (.mailmap: fix broken line with multiple emails)
- rust-lang/rust#153573 (rustdoc-json: fix incorrect documentation for VariantKind::Struct)
Failed merges:
- rust-lang/rust#153509 (Cleanup unused diagnostic emission methods - part 2)
rustdoc-json: fix incorrect documentation for VariantKind::Struct
Seems to have been copy-and-pasted from `Enum::variants`, but `VariantKind::Struct::fields` is for struct variant fields, not enum variants.
num: Separate public API from internal implementations
Currently we have a single `core::num` module that contains both thin wrapper API and higher-complexity numeric routines. Restructure this by moving implementation details to a new `imp` module.
This results in a more clean separation of what is actually user-facing compared to items that have a stability attribute because they are public for testing.
The first commit does the actual change then the second moves a portion back.
Inline and simplify some code for saving incremental data to disk
Main changes:
- Inline `encode_query_cache` and `TyCtxt::serialize_query_result_cache`
- Pull value promotion out of `OnDiskCache::drop_serialized_data`
- Panic if `on_disk_cache` is None in an incremental-only path
Update `UnsafeUnpin` impls involving extern types.
`UnsafeUnpin` tracking issue: https://github.com/rust-lang/rust/issues/125735
Relaxes from `T: ?Sized` (i.e. `T: MetaSized`) to `T: PointeeSized` for the `UnsafeUnpin` impls for pointers, references, and `PhantomData<T>`, and for the negative `UnsafeUnpin` impl for `UnsafePinned<T>`. (Compare to the impls for `Freeze` on lines 911-921.)
Both `UnsafeUnpin` and `extern type`s (the only way to have a `!MetaSized` type) are unstable, so this should have no effect on stable code.
Also updates the marker_impls macro docs to use PointeeSized bound, as most uses of the macro now do.
Concretely, this change means that the following types will newly implement `UnsafeUnpin`:
* pointers and references to `T` where `T` is an `extern type`
* `PhantomData<T>` where `T` is an extern type
* either of the above where `T` is a `struct` or tuple with `extern type` tail
Additionally, the negative `UnsafeUnpin` impl for `UnsafePinned<T>` is also relaxed to `T: PointeeSized` to align with the analogous negative `Freeze` impl for `UnsafeCell<T>`, even though both structs have `T: ?Sized` in their declaration (which probably should be relaxed, but that is a separate issue), so this part of the change doesn't actually *do* anything currently, but if `UnsafeCell` and `UnsafePinned` are later relaxed to `T: PointeeSized`, then the negative impl will apply to the newly possible instantiations. Also cc https://github.com/rust-lang/rust/issues/152645 that these impls compile at all.
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#153464 (Use `&C::Key` less in queries.)
- rust-lang/rust#153553 (Remove the `rustc_data_structures::assert_matches!` re-exports)
- rust-lang/rust#153561 (Replace the `try_mark_green` hook with direct calls to `tcx.dep_graph`)
- rust-lang/rust#153564 (rendering interpreter OOM as OOM instead of ICE)
Replace the `try_mark_green` hook with direct calls to `tcx.dep_graph`
All of the existing call sites are directly touching `tcx.dep_graph` anyway, so the extra layer of indirection provides no real benefit.
There should be no change to compiler behaviour.
r? nnethercote (or compiler)
Remove the `rustc_data_structures::assert_matches!` re-exports
- https://github.com/rust-lang/rust/pull/151359
- https://github.com/rust-lang/rust/pull/153462
---
Now that the bootstrap stage0 compiler has been bumped to 1.95, we can remove these temporary re-exports from `rustc_data_structures`, and once again import the `assert_matches!` macros directly from std.
Use `&C::Key` less in queries.
Currently we use a mix of `C::Key` and `&C::Key` parameters. The former is more common and a bit nicer, so convert some of the latter. This results in less converting between the two types, and fewer sigils.
Currently we use a mix of `C::Key` and `&C::Key` parameters. The former
is more common and a bit nicer, so convert some of the latter. This
results in less converting between the two types, and fewer sigils.
Main changes:
- Inline `encode_query_cache` and `TyCtxt::serialize_query_result_cache`
- Pull value promotion out of `OnDiskCache::drop_serialized_data`
- Panic if `on_disk_cache` is None in an incremental-only path
Overhaul `ensure_ok`
The interaction of `ensure_ok` and the `return_result_from_ensure_ok` query modifier is weird and hacky. This PR cleans it up. Details in the individual commits.
r? @Zalathar
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#153202 ([win] Fix truncated unwinds for Arm64 Windows)
- rust-lang/rust#153437 (coretest in miri: fix using unstable libtest features)
- rust-lang/rust#153446 (Always use the ThinLTO pipeline for pre-link optimizations)
- rust-lang/rust#153548 (add test for closure precedence in `TokenStream`s)
Always use the ThinLTO pipeline for pre-link optimizations
When using cargo this was already effectively done for all dependencies as cargo passes -Clinker-plugin-lto without -Clto=fat/thin. -Clinker-plugin-lto assumes that ThinLTO will be used. The ThinLTO pre-link pipeline is faster than the fat LTO one. And according to the benchmarks in [^1] there is barely any runtime performance difference between executables that used fat LTO with the fat vs ThinLTO pre-link pipeline.
This also helps avoid having yet another code path if we want to support Unified LTO (that is a single bitcode file that supports being used for both fat LTO and ThinLTO when using linker plugin LTO, we already support it when rustc does LTO as ThinLTO bitcode is enough of a superset of fat LTO bitcode that it happens to work by accident if you don't explicitly have a check preventing mixing of them for the current set of LTO features that rustc exposes.) I'm currently still investigating if rustc would benefit from Unified LTO and how exactly to integrate it.
[^1]: https://discourse.llvm.org/t/rfc-a-unified-lto-bitcode-frontend/61774
Guillaume Gomez