Allow vector types for amdgpu
The amdgpu target uses vector types in various places. The vector types can be used on all architectures, there is no associated target feature that needs to be enabled.
The largest vector type found in LLVM intrinsics is `v32i32` (`[32 x i32]`) for mfma intrinsics. Note that while this intrinsic is only supported on some architectures, the vector type itself is supported on all architectures.
Tracking issue: rust-lang/rust#135024
(I used an empty string to say “does not need a target feature”. If you prefer an `Option` or something like that, I’ll change it.)
don't use no_main and no_core to test IBT
The previous test was quite fragile and depended on a bunch of internal features. Simplify it.
Split out of https://github.com/rust-lang/rust/pull/149937.
cc ```@jieyouxu``` ```@Oneirical```
The amdgpu target uses vector types in various places. The vector types
can be used on all architectures, there is no associated target feature
that needs to be enabled.
The largest vector type found in LLVM intrinsics is `v32i32`
(`[32 x i32]`) for mfma intrinsics. Note that while this intrinsic is
only supported on some architectures, the vector type itself is
supported on all architectures.
Don't leak sysroot crates through dependencies
Previously if a dependency of the current crate depended on a sysroot crate, then `extern crate` would in the current crate would pick the first loaded version of said sysroot crate even in case of an ambiguity. This is surprising and brittle. For `-Ldependency=` we already blocked this since rust-lang/rust#110229, but the fix didn't account for sysroot crates.
Should fix https://github.com/rust-lang/rust/issues/147966
Overhaul filename handling for cross-compiler consistency
This PR overhauls the way we handle filenames in the compiler and `rmeta` in order to achieve achieve cross-compiler consistency (ie. having the same path no matter if the filename was created in the current compiler session or is coming from `rmeta`).
This is required as some parts of the compiler rely on consistent paths for the soundness of generated code (see rust-lang/rust#148328).
In order to achieved consistency multiple steps are being taken by this PR:
- by making `RealFileName` immutable
- by only having `SourceMap::to_real_filename` create `RealFileName`
- currently `RealFileName` can be created from any `Path` and are remapped afterwards, which creates consistency issue
- by also making `RealFileName` holds it's working directory, embeddable name and the remapped scopes
- this removes the need for a `Session`, to know the current(!) scopes and cwd, which is invalid as they may not be equal to the scopes used when creating the filename
In order for `SourceMap::to_real_filename` to know which scopes to apply `FilePathMapping` now takes the current remapping scopes to apply, which makes `FileNameDisplayPreference` and company useless and are removed.
This PR is split-up in multiple commits (unfortunately not atomic), but should help review the changes.
Unblocks https://github.com/rust-lang/rust/pull/147611
Fixes https://github.com/rust-lang/rust/issues/148328
This commit refactors `SourceMap` and most importantly `RealFileName` to
make it self-contained in order to achieve cross-compiler consistency.
This is achieved:
- by making `RealFileName` immutable
- by only having `SourceMap::to_real_filename` create `RealFileName`
- by also making `RealFileName` holds it's working directory,
it's embeddable name and the remapped scopes
- by making most `FileName` and `RealFileName` methods take a scope as
an argument
In order for `SourceMap::to_real_filename` to know which scopes to apply
`FilePathMapping` now takes the current remapping scopes to apply, which
makes `FileNameDisplayPreference` and company useless and are removed.
The scopes type `RemapPathScopeComponents` was moved from
`rustc_session::config` to `rustc_span`.
The previous system for scoping the local/remapped filenames
`RemapFileNameExt::for_scope` is no longer useful as it's replaced by
methods on `FileName` and `RealFileName`.
rustdoc: Add unstable `--merge-doctests=yes/no/auto` flag
This is useful for changing the *default* for whether doctests are merged or not. Currently, that default is solely controlled by `edition = 2024`, which adds a high switching cost to get doctest merging. This flag allows opting in even on earlier editions.
Unlike the `edition = 2024` default, `--merge-doctests=yes` gives a hard error if merging fails instead of falling back to running standalone tests. The user has explicitly said they want merging, so we shouldn't silently do something else.
`--merge-doctests=auto` is equivalent to the current 2024 edition behavior, but available on earlier editions.
Helps with https://github.com/rust-lang/rust/issues/141240. ``@epage`` said in that issue he would like a per-doctest opt-in, and that seems useful to me in addition to this flag, but I think it's a separate use case from changing the default.
unstable proc_macro tracked::* rename/restructure
Picking up what should be the uncontroversial part of rust-lang/rust#87173 (closed due to inactivity over two years ago).
Part of rust-lang/rust#99515.
- move `proc_macro::tracked_env::var` to `proc_macro::tracked::env_var`
- move `proc_macro::tracked_path::path` to `proc_macro::tracked::path`
- change the argument of `proc_macro::tracked::path` from `AsRef<str>` to `AsRef<Path>`.
`c_variadic`: make `VaList` abi-compatible with C
tracking issue: https://github.com/rust-lang/rust/issues/44930
related PR: rust-lang/rust#144529
On some platforms, the C `va_list` type is actually a single-element array of a struct (on other platforms it is just a pointer). In C, arrays passed as function arguments expirience array-to-pointer decay, which means that C will pass a pointer to the array in the caller instead of the array itself, and modifications to the array in the callee will be visible to the caller (this does not match Rust by-value semantics). However, for `va_list`, the C standard explicitly states that it is undefined behaviour to use a `va_list` after it has been passed by value to a function (in Rust parlance, the `va_list` is moved, not copied). This matches Rust's pass-by-value semantics, meaning that when the C `va_list` type is a single-element array of a struct, the ABI will match C as long as the Rust type is always be passed indirectly.
In the old implementation, this ABI was achieved by having two separate types: `VaList` was the type that needed to be used when passing a `VaList` as a function parameter, whereas `VaListImpl` was the actual `va_list` type that was correct everywhere else. This however is quite confusing, as there are lots of footguns: it is easy to cause bugs by mixing them up (e.g. the C function `void foo(va_list va)` was equivalent to the Rust `fn foo(va: VaList)` whereas the C function `void bar(va_list* va)` was equivalent to the Rust `fn foo(va: *mut VaListImpl)`, not `fn foo(va: *mut VaList)` as might be expected); also converting from `VaListImpl` to `VaList` with `as_va_list()` had platform specific behaviour: on single-element array of a struct platforms it would return a `VaList` referencing the original `VaListImpl`, whereas on other platforms it would return a cioy,
In this PR, there is now just a single `VaList` type (renamed from `VaListImpl`) which represents the C `va_list` type and will just work in all positions. Instead of having a separate type just to make the ABI work, rust-lang/rust#144529 adds a `#[rustc_pass_indirectly_in_non_rustic_abis]` attribute, which when applied to a struct will force the struct to be passed indirectly by non-Rustic calling conventions. This PR then implements the `VaList` rework, making use of the new attribute on all platforms where the C `va_list` type is a single-element array of a struct.
Cleanup of the `VaList` API and implementation is also included in this PR: since it was decided it was OK to experiment with Rust requiring that not calling `va_end` is not undefined behaviour (https://github.com/rust-lang/rust/issues/141524#issuecomment-3028383594), I've removed the `with_copy` method as it was redundant to the `Clone` impl (the `Drop` impl of `VaList` is a no-op as `va_end` is a no-op on all known platforms).
Previous discussion: rust-lang/rust#141524 and [t-compiler > c_variadic API and ABI](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/c_variadic.20API.20and.20ABI)
Tracking issue: https://github.com/rust-lang/rust/issues/44930
r? `@joshtriplett`
Tests for `-Zdebuginfo-compression=zstd` need to be skipped if LLVM was built
without support for zstd compression.
Currently, compiletest relies on messy and fragile heuristics to detect whether
the compiler's LLVM was built with zstd support. But the compiler itself
already knows whether LLVM has zstd or not, so it's easier for compiletest to
just ask the compiler.
This is useful for changing the *default* for whether doctests are
merged or not. Currently, that default is solely controlled by
`edition = 2024`, which adds a high switching cost to get doctest
merging. This flag allows opt-ing in even on earlier additions.
Unlike the `edition = 2024` default, `--merge-doctests=yes` gives a hard
error if merging fails instead of falling back to running standalone
tests. The user has explicitly said they want merging, so we shouldn't
silently do something else.
`--merge-doctests=auto` is equivalent to the current 2024 edition
behavior, but available on earlier editions.
rustdoc: make mergeable crate info more usable
Part of https://github.com/rust-lang/rust/issues/130676
Adds documentation and a feature change aimed at making this usable without breaking backwards compat.
cc ``@EtomicBomb``
rustdoc-json: add rlib path to ExternalCrate to enable robust crate resolution
Historically, it's not been possible to robustly resolve a cross-crate item in rustdoc-json. If you had a `Id` that wasn't in `Crate::index` (because it was defined in a different crate), you could only look it up it `Crate::paths`. But there, you don't get the full information, only an `ItemSummary`. This tells you the `path` and the `crate_id`.
But knowing the `crate_id` isn't enough to be able to build/find the rustdoc-json output with this item. It's only use is to get a `ExternalCrate` (via `Crate::external_crates`). But that only tells you the `name` (as a string). This isn't enough to uniquely identify a crate, as there could be multiple versions/features [^1] [^2].
This was originally proposed to be solved via `@LukeMathWalker's` `--orchestrator-id` proposal (https://github.com/rust-lang/compiler-team/issues/635). But that requires invasive changes to cargo/rustc. This PR instead implements `@Urgau's` proposal to re-use the path to a crate's rmeta/rlib as a unique identifer. Callers can use that to determine which package it corresponds to in the language of the build-system above rustc. E.g. for cargo, `cargo rustdoc --message-format=json --output-format=json -Zunstable-options`).
(Once you've found the right external crate's rustdoc-json output, you still need to resolve the path->id in that crate. But that's """just""" a matter of walking the module tree. We should probably still make that nicer (by, for example, allowing sharing `Id`s between rustdoc-json document), but that's a future concern)
For some notes from RustWeek 2025, where this was designed, see https://hackmd.io/0jkdguobTnW7nXoGKAxfEQ
CC `@obi1kenobi` (who wants this for cargo-semver-checks [^3]), `@epage` (who's conversations on what and wasn't possible with cargo informed taking this approach to solve this problem)
r? `@GuillaumeGomez`
## TODO:
- [x] Docs: [Done](https://github.com/rust-lang/rust/compare/e4cdd0c24a994fed354081b5f907680a11f2ddc5..457ed4edb184997d5d6f879c6a220bc4d69ff6fd)
- [x] Tests: [Done](https://github.com/rust-lang/rust/compare/2e1b954dc52bf7e5a6e9311394df760db37d383f..4d00c1a7ee5e03d1e78801cc01a85dac08ab603b)
[^1]: https://github.com/rust-lang/compiler-team/issues/635#issue-1714254865 § Problem
[^2]: https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/Identifying.20external.20crates.20in.20Rustdoc.20JSON/with/352701211
[^3]: https://github.com/obi1kenobi/cargo-semver-checks/issues/638
Historically, it's not been possible to robustly resolve a cross-crate
item in rustdoc-json. If you had a `Id` that wasn't in `Crate::index`
(because it was defined in a different crate), you could only look it up
it `Crate::paths`. But there, you don't get the full information, only
an `ItemSummary`. This tells you the `path` and the `crate_id`.
But knowing the `crate_id` isn't enough to be able to build/find the
rustdoc-json output with this item. It's only use is to get a
`ExternalCrate` (via `Crate::external_crates`). But that only tells you
the `name` (as a string). This isn't enough to uniquely identify a
crate, as there could be multiple versions/features [1] [2].
This was originally proposed to be solved via LukeMathWalker's
`--orchestrator-id` proposal
(https://www.github.com/rust-lang/compiler-team/issues/635). But that
requires invasive changes to cargo/rustc. This PR instead implements
Urgau's proposal to re-use the path to a crate's rmeta/rlib as a unique
identifer. Callers can use that to determine which package it
corresponds to in the language of the build-system above rustc. E.g. for
cargo, `cargo rustdoc --message-format=json --output-format=json
-Zunstable-options`).
(Once you've found the right external crate's rustdoc-json output, you
still need to resolve the path->id in that crate. But that's """just"""
a matter of walking the module tree. We should probably still make that
nicer (by, for example, allowing sharing `Id`s between rustdoc-json
document), but that's a future concern)
For some notes from RustWeek 2025, where this was designed, see
https://hackmd.io/0jkdguobTnW7nXoGKAxfEQ
[1]: https://www.github.com/rust-lang/compiler-team/issues/635#issue-1714254865 § Problem
[2]: https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/Identifying.20external.20crates.20in.20Rustdoc.20JSON/with/352701211
This is useful when you have two dependencies that use different trait for
the same thing and with the same name. The user can accidentally implement
the bad one which might be confusing. This commits refactorizes existing
diagnostics about multiple different crates with the same version and adds
a note when similarly named traits are found. All diagnostics are merged
into a single one.
Adds missing test coverage for rustdoc's `--test-builder` option.
The existing test only covered the error case (non-executable builder). This PR
adds:
- A custom test builder that logs arguments and forwards to rustc
- A test verifying that `--test-builder` successfully invokes the custom
builder with rustc-style arguments
- Improved comments explaining both the error and success test scenarios
The test validates that custom builders can properly intercept and handle
doctest compilation.
Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
rustdoc: Use configured target modifiers when collecting doctests
To support loading dependencies with target modifiers and avoid ABI mismatch errors.
Fixesrust-lang/rust#146465.
This test suffers from multiple issues that make it very, very difficult
to fix, and even if fixed, it would still be too fragile.
For some background context, this test tries to check that the
optimization introduced in [PR-78122] is not regressed. The optimization
is for eliding `usize` formatting machinery and padding code from the
final binary.
Previously, writing any `fmt::Arguments` would cause the `usize`
formatting and padding machinery to be included in the final binary
since indexing used in `fmt::write` generates code using
`panic_bounds_check` (that prints the index and length). Those bounds
check are never hit, since `fmt::Arguments` never contain any
out-of-bounds indicies.
The `Makefile` version of `fmt-write-bloat` was ported to the present
`rmake.rs` test infra in [PR-128147]. However, this PR just tries to
maintain the original test logic.
The original test, it turns out, already have multiple limitations:
- It only runs on non-Windows, since the `no_std` test of the original
version tries to link against a `libc`. [PR-128807] worked around this
by using a substitute name. We re-enabled this test in [PR-142841],
but it turns out the assertions are too weak, it will even vacuously
pass for no symbols at all.
- In [PR-143669], we tried to make this test more robust by comparing
the set of expected versus unexpected panic-related symbols, subject
to if std was built with debug assertions.
However, in working on [PR-143669], we've come to realize that this test
is fundamentally very fragile:
- The set of panic symbols depend on whether the standard library was
built with or without debug assertions.
- Different platforms often have different sets of panic
machinery modules, functions and paths, and thus different sets of
panic symbols. For instance, x86_64 msvc and i686 msvc have different
panic codepaths.
- This comes back to the way the test is trying to gauge the absence of
panic symbols -- it tries to look for symbol substring matches for
"known" panic symbols. This is fundamentally fragile, because the test
is trying to peek into the symbols of the resultant binary
post-linking, based on fuzzy matches (the symbols are mangled as
well).
Based on this assessment, we determined that we should remove this test.
This is not intended to exclude the possibility of reintroducing a more
robust version of this test. For instance, we could consider some kind
of more controllable post-link "end product" integration codegen test
suite.
[PR-78122]: https://github.com/rust-lang/rust/pull/78122
[PR-128147]: https://github.com/rust-lang/rust/pull/128147
[PR-128807]: https://github.com/rust-lang/rust/pull/128807
[PR-142841]: https://github.com/rust-lang/rust/pull/142841
[PR-143669]: https://github.com/rust-lang/rust/pull/143669
rustdoc: Rename unstable option `--nocapture` to `--no-capture` in accordance with `libtest`
Context: https://github.com/rust-lang/rust/issues/133073, https://github.com/rust-lang/rust/pull/139224 (TL;DR: `libtest` has soft-deprecated `--nocapture` in favor a new & stable `--no-capture`; we should follow suit).
Since the rustdoc flag is unstable (tracking issue: https://github.com/rust-lang/rust/issues/148116), we're allowed to remove the old flag immediately. However since the flag has existed for 4 years we could hard-deprecate the flag first or at least be considerate and provide a diagnostic referring users to the new flag. This PR does neither. Let me know what you would think would be best.
Cargo doesn't use this flag, not yet at least (https://github.com/rust-lang/cargo/pull/9705), so we really are free to sunset this flag without bigger consequences.
Matthias Krüger