Rollup of 7 pull requests #134223
Merged
Rollup of 7 pull requests #134223
Conversation
This file contains 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
LoongArch psABI[^1] specifies that LSX vector types are passed via general-purpose
registers, while LASX vector types are passed indirectly through the stack.
This patch addresses the following warnings:
```
warning: this function call uses a SIMD vector type that is not currently supported with the chosen ABI
--> .../library/core/src/../../stdarch/crates/core_arch/src/loongarch64/lsx/generated.rs:3695:5
|
3695 | __lsx_vreplgr2vr_b(a)
| ^^^^^^^^^^^^^^^^^^^^^ function called here
|
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue rust-lang#116558 <rust-lang#116558>
= note: `#[warn(abi_unsupported_vector_types)]` on by default
```
[^1]: https://github.com/loongson/la-abi-specs/blob/release/lapcs.adoc
In the LLVM-C API, boolean values are passed as `typedef int LLVMBool`, but our Rust-side typedef was using `c_uint` instead. Signed and unsigned integers have the same ABI on most platforms, but that isn't universally true, so we should prefer to be consistent with LLVM.
Add unpolished, experimental support for AFIDT (async fn in dyn trait)
This allows us to begin messing around `async fn` in `dyn Trait`. Calling an async fn from a trait object always returns a `dyn* Future<Output = ...>`.
To make it work, Implementations are currently required to return something that can be coerced to a `dyn* Future` (see the example in `tests/ui/async-await/dyn/works.rs`). If it's not the right size, then it'll raise an error at the coercion site (see the example in `tests/ui/async-await/dyn/wrong-size.rs`). Currently the only practical way of doing this is wrapping the body in `Box::pin(async move { .. })`.
This PR does not implement a helper type like a "`Boxing`"[^boxing] adapter, and I'll probably follow-up with another PR to improve the error message for the `PointerLike` trait (something that explains in just normal prose what is happening here, rather than a trait error).
[^boxing]: https://rust-lang.github.io/async-fundamentals-initiative/explainer/user_guide_future.html#the-boxing-adapter
This PR also does not implement new trait solver support for AFIDT; I'll need to think how best to integrate it into candidate assembly, and that's a bit of a matter of taste, but I don't think it will be difficult to do.
This could also be generalized:
* To work on functions that are `-> impl Future` (soon).
* To work on functions that are `-> impl Iterator` and other "dyn rpitit safe" traits. We still need to nail down exactly what is needed for this to be okay (not soon).
Tracking:
* rust-lang#133119
…ubilee
ABI checks: add support for loongarch
LoongArch psABI[^1] specifies that LSX vector types are passed via general-purpose registers, while LASX vector types are passed indirectly through the stack.
This patch addresses the following warnings:
```
warning: this function call uses a SIMD vector type that is not currently supported with the chosen ABI
--> .../library/core/src/../../stdarch/crates/core_arch/src/loongarch64/lsx/generated.rs:3695:5
|
3695 | __lsx_vreplgr2vr_b(a)
| ^^^^^^^^^^^^^^^^^^^^^ function called here
|
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue rust-lang#116558 <rust-lang#116558>
= note: `#[warn(abi_unsupported_vector_types)]` on by default
```
[^1]: https://github.com/loongson/la-abi-specs/blob/release/lapcs.adoc
r? `@workingjubilee`
Use newly added exceptions to non default branch warning cc rust-lang/triagebot#1860 cc `@cuviper` r? `@ehuss`
Bump Fuchsia try-job: x86_64-fuchsia
Fix our `llvm::Bool` typedef to be signed, to match `LLVMBool` In the LLVM-C API, boolean values are passed as `typedef int LLVMBool`, but our Rust-side typedef was using `c_uint` instead. Signed and unsigned integers have the same ABI on most platforms, but that isn't universally true, so we should prefer to be consistent with LLVM. https://github.com/rust-lang/llvm-project/blob/1268e87/llvm/include/llvm-c/Types.h#L28
Revert "bootstrap: print{ln}! -> eprint{ln}! (take 2) rust-lang#134040"
Unfortunately, rust-lang#134040 is proving to have caused more output interleaving problems that are tricky to diagnose and fix, and I think we probably should leave these untouched as bootstrap and compiletest has a bunch of interconnecting parts, and the commands and tools that they exercise do not consistently use stderr/stdout either. This causes hard-to-diagnose output interleaving bugs, which unfortunately degrades contributor experience.
This PR reverts two PRs in order to cleanly revert rust-lang#134040:
1. Revert rust-lang#134123 which is a fix-forward after rust-lang#134040.
2. Revert rust-lang#134040 itself.
I don't regret the initial effort `@clubby789,` and thank you for making the attempts, but I think we need to refrain from touching too many of these at once because some of the interleaving are very non-obvious and we don't have test coverage for.
r? `@clubby789`
cc `@Zalathar`
rustdoc: fix self cmp Looks like condition in `filter` currently always `true`, but intended to compare with `fqp` from `if let Some(&(ref fqp, item_type))`?
rustbot
added
A-compiletest
|
@bors r+ rollup=never p=7 |
bors
added
S-waiting-on-bors
|
|
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: a94fce97e3 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
|
Finished benchmarking commit (d4025ee): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 771.536s -> 770.02s (-0.20%) |
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:
llvm::Booltypedef to be signed, to matchLLVMBool#134204 (Fix ourllvm::Booltypedef to be signed, to matchLLVMBool)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup