Rollup of 21 pull requests #144995
Closed
Rollup of 21 pull requests #144995
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…for break_ok/continue_ok
Add target features for sm_* and ptx*, both of which form a partial order, but cannot be combined to a single partial order. These mirror the LLVM target features, but we do not provide LLVM target processors (which imply both an sm_* and ptx* feature). Add some documentation for the nvptx target.
Normally LLVM and rustc agree about what features are implied by
target-cpu, but for NVPTX, LLVM considers sm_* and ptx* features to be
exclusive, which makes sense for codegen purposes. But in Rust, we want
to think of them as:
sm_{sver} means that the target supports the hardware features of sver
ptx{pver} means the driver supports PTX ISA pver
Intrinsics usually require a minimum sm_{sver} and ptx{pver}.
Prior to this commit, -Ctarget-cpu=sm_70 would activate only sm_70 and
ptx60 (the minimum PTX version that supports sm_70, which maximizes
driver compatibility). With this commit, it also activates all the
implied target features (sm_20, ..., sm_62; ptx32, ..., ptx50).
This is already warn-by-default, and a future compatibility warning (FCW) that warns in dependencies. Upgrade it to deny-by-default, as the next step towards hard error.
With this macro we only need to enumerate every variant once. This saves a lot of duplication already between the definition, the `FromStr` impl and the `ToJson` impl. It also enables us to do further things with it like JSON schema generation.
Co-authored-by: Tshepang Mbambo <[email protected]>
We noticed when building rustc multiple time in a roll, some files will not be consistent across the build despite the fact that they are built from same source under the same environment. This patch addresses the inconsistency issue we found on libunwind.a by sorting the order of the files passed to the linker.
This schema is helpful for people writing custom target spec JSON. It can provide autocomplete in the editor, and also serves as documentation when there are documentation comments on the structs, as `schemars` will put them in the schema.
Currently the Args new function is scope constrained to pub(super) but this stops me from being able to construct Args structs in unit tests.
Make suggestions to remove params and super traits tool-only, and make
the suggestion span more accurate.
```
error[E0567]: auto traits cannot have generic parameters
--> $DIR/auto-trait-validation.rs:6:19
|
LL | auto trait Generic<T> {}
| -------^^^
| |
| auto trait cannot have generic parameters
error[E0568]: auto traits cannot have super traits or lifetime bounds
--> $DIR/auto-trait-validation.rs:8:20
|
LL | auto trait Bound : Copy {}
| ----- ^^^^
| |
| auto traits cannot have super traits or lifetime bounds
```
```
error[E0380]: auto traits cannot have associated items
--> $DIR/issue-23080.rs:5:8
|
LL | unsafe auto trait Trait {
| ----- auto traits cannot have associated items
LL | fn method(&self) {
| ^^^^^^
```
Make sure that compiler and linker don't optimize the section's contents away by adding the global holding the data to "llvm.used". The volatile load in the main shim is retained because "llvm.used", which translates to SHF_GNU_RETAIN on ELF targets, requires a reasonably recent linker; emitting the volatile load ensures compatibility with older linkers, at least when libstd is used. Pretty printers in dylib dependencies are now emitted by the main crate instead of the dylib; apart from matching how rlibs are handled, this approach has the advantage that `omit_gdb_pretty_printer_section` keeps working with dylib dependencies.
Instead of collecting pretty printers transitively when building executables/staticlibs/cdylibs, let the debugger find each crate's pretty printers via its .debug_gdb_scripts section. This covers the case where libraries defining custom pretty printers are loaded dynamically.
|
@bors r+ rollup=never p=5 |
bors
added
S-waiting-on-bors
bors
added a commit
that referenced
this pull request
Aug 6, 2025
Rollup of 21 pull requests Successful merges: - #137831 (Tweak auto trait errors) - #138689 (add nvptx_target_feature) - #140267 (implement continue_ok and break_ok for ControlFlow) - #143679 (Preserve the .debug_gdb_scripts section) - #143857 (Port #[macro_export] to the new attribute parsing infrastructure) - #143929 (Mark all deprecation lints in name resolution as deny-by-default and report-in-deps) - #144133 (Stabilize const TypeId::of) - #144369 (Upgrade semicolon_in_expressions_from_macros from warn to deny) - #144473 (Address libunwind.a inconsistency issues in the bootstrap program) - #144498 (Add --print target-spec-json-schema) - #144552 (Rehome 33 `tests/ui/issues/` tests to other subdirectories under `tests/ui/`) - #144659 (bootstrap: refactor mingw dist and fix gnullvm) - #144676 (Add documentation for unstable_feature_bound) - #144794 (Port `#[coroutine]` to the new attribute system) - #144835 (Anonymize binders in tail call sig) - #144836 (Change visibility of Args new function) - #144861 (Stabilize `panic_payload_as_str` feature) - #144910 (Add regression tests for seemingly fixed issues) - #144913 ([rustdoc] Fix wrong `i` tooltip icon) - #144917 (Enforce tail call type is related to body return type in borrowck) - #144924 (compiletest: add hint for when a ui test produces no errors) r? `@ghost` `@rustbot` modify labels: rollup
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
|
I can't see any useful information in the failure log, so I have no way to identify a likely cause. |
|
Let's see if this is even reproducible: @bors try jobs=dist-ohos-x86_64 |
rust-bors bot
added a commit
that referenced
this pull request
Aug 6, 2025
Rollup of 21 pull requests try-job: dist-ohos-x86_64
|
💔 Test failed (CI). Failed jobs:
|
|
The job Click to see the possible cause of the failure (guessed by this bot) |
rustbot
removed
the
S-waiting-on-review
This was referenced Aug 7, 2025
|
Via #145034 I have narrowed the failure down to 6 suspects:
I've started a |
|
The cause seems to have been #144498. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
tests/ui/issues/tests to other subdirectories undertests/ui/#144552 (Rehome 33tests/ui/issues/tests to other subdirectories undertests/ui/)#[coroutine]to the new attribute system #144794 (Port#[coroutine]to the new attribute system)panic_payload_as_strfeature #144861 (Stabilizepanic_payload_as_strfeature)itooltip icon #144913 ([rustdoc] Fix wrongitooltip icon)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup