Infer async closure args from `Fn` bound even if there is no corresponding `Future` bound on return
In #127482, I implemented the functionality to infer an async closure signature when passed into a function that has `Fn` + `Future` where clauses that look like:
```
fn whatever(callback: F)
where
F: Fn(Arg) -> Fut,
Fut: Future<Output = Out>,
```
However, #127781 demonstrates that this is still incomplete to address the cases users care about. So let's not bail when we fail to find a `Future` bound, and try our best to just use the args from the `Fn` bound if we find it. This is *fine* since most users of closures only really care about the *argument* types for inference guidance, since we require the receiver of a `.` method call to be known in order to probe methods.
When I experimented with programmatically rewriting `|| async {}` to `async || {}` in #127827, this also seems to have fixed ~5000 regressions (probably all coming from usages `TryFuture`/`TryStream` from futures-rs): the [before](https://github.com/rust-lang/rust/pull/127827#issuecomment-2254061733) and [after](https://github.com/rust-lang/rust/pull/127827#issuecomment-2255470176) crater runs.
Fixes#127781.
Unconditionally allow shadow call-stack sanitizer for AArch64
It is possible to do so whenever `-Z fixed-x18` is applied.
cc ``@Darksonn`` for context
The reasoning is that, as soon as reservation on `x18` is forced through the flag `fixed-x18`, on AArch64 the option to instrument with [Shadow Call Stack sanitizer](https://clang.llvm.org/docs/ShadowCallStack.html) is then applicable regardless of the target configuration.
At the every least, we would like to relax the restriction on specifically `aarch64-unknonw-none`. For this option, we can include a documentation change saying that users of compiled objects need to ensure that they are linked to runtime with Shadow Call Stack instrumentation support.
Related: #121972
Rework MIR inlining debuginfo so function parameters show up in debuggers.
Line numbers of multiply-inlined functions were fixed in #114643 by using a single DISubprogram. That, however, triggered assertions because parameters weren't deduplicated. The "solution" to that in #115417 was to insert a DILexicalScope below the DISubprogram and parent all of the parameters to that scope. That fixed the assertion, but debuggers (including gdb and lldb) don't recognize variables that are not parented to the subprogram itself as parameters, even if they are emitted with DW_TAG_formal_parameter.
Consider the program:
```rust
use std::env;
#[inline(always)]
fn square(n: i32) -> i32 {
n * n
}
#[inline(never)]
fn square_no_inline(n: i32) -> i32 {
n * n
}
fn main() {
let x = square(env::vars().count() as i32);
let y = square_no_inline(env::vars().count() as i32);
println!("{x} == {y}");
}
```
When making a release build with debug=2 and rustc 1.82.0-nightly (8b3870784 2024-08-07)
```
(gdb) r
Starting program: /ephemeral/tmp/target/release/tmp [Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, tmp::square () at src/main.rs:5
5 n * n
(gdb) info args
No arguments.
(gdb) info locals
n = 31
(gdb) c
Continuing.
Breakpoint 2, tmp::square_no_inline (n=31) at src/main.rs:10
10 n * n
(gdb) info args
n = 31
(gdb) info locals
No locals.
```
This issue is particularly annoying because it removes arguments from stack traces.
The DWARF for the inlined function looks like this:
```
< 2><0x00002132 GOFF=0x00002132> DW_TAG_subprogram
DW_AT_linkage_name _ZN3tmp6square17hc507052ff3d2a488E
DW_AT_name square
DW_AT_decl_file 0x0000000f /ephemeral/tmp/src/main.rs
DW_AT_decl_line 0x00000004
DW_AT_type 0x00001a56<.debug_info+0x00001a56>
DW_AT_inline DW_INL_inlined
< 3><0x00002142 GOFF=0x00002142> DW_TAG_lexical_block
< 4><0x00002143 GOFF=0x00002143> DW_TAG_formal_parameter
DW_AT_name n
DW_AT_decl_file 0x0000000f /ephemeral/tmp/src/main.rs
DW_AT_decl_line 0x00000004
DW_AT_type 0x00001a56<.debug_info+0x00001a56>
< 4><0x0000214e GOFF=0x0000214e> DW_TAG_null
< 3><0x0000214f GOFF=0x0000214f> DW_TAG_null
```
That DW_TAG_lexical_block inhibits every debugger I've tested from recognizing 'n' as a parameter.
This patch removes the additional lexical scope. Parameters can be easily deduplicated by a tuple of their scope and the argument index, at the trivial cost of taking a Hash + Eq bound on DIScope.
Use the `enum2$` Natvis visualiser for repr128 C-style enums
Use the preexisting `enum2$` Natvis visualiser to allow PDB debuggers to display fieldless `#[repr(u128)]]`/`#[repr(i128)]]` enums correctly.
Tracking issue: #56071
try-job: x86_64-msvc
Add possibility to generate rustdoc JSON output to stdout
Fixes#127165.
I think it's likely common to want to get rustdoc json output directly instead of reading it from a file so I added this option to allow it. It's unstable and only works with `--output-format=json`.
r? `@aDotInTheVoid`
derive(SmartPointer): register helper attributes
Fix#128888
This PR enables built-in macros to register helper attributes, if any, to support correct name resolution in the correct lexical scope under the macros.
Also, `#[pointee]` is moved into the scope under `derive(SmartPointer)`.
cc `@Darksonn` `@davidtwco`
Add powerpc-unknown-linux-muslspe compile target
This is almost identical to already existing targets:
- powerpc_unknown_linux_musl.rs
- powerpc_unknown_linux_gnuspe.rs
It has support for PowerPC SPE (muslspe), which
can be used with GCC version up to 8. It is useful for Freescale or IBM cores like e500.
This was verified to be working with OpenWrt build system for CZ.NIC's Turris 1.x routers, which are using Freescale P2020, e500v2, so add it as a Tier 3 target.
Follow-up of https://github.com/rust-lang/rust/pull/100860
CommandExt::before_exec: deprecate safety in edition 2024
Similar to `set_var`, we had to find out after 1.0 was released that `before_exec` should have been unsafe. We partially rectified this by deprecating that function a long time ago, but since https://github.com/rust-lang/rust/pull/124636 we have the ability to also deprecate the safety of the old function and make it a *hard error* to call the old function outside `unsafe` in the next edition. So just in case anyone still uses the old function, let's ensure this can't be ignored when moving code to the new edition.
Cc `@rust-lang/libs-api`
Tracking:
- https://github.com/rust-lang/rust/issues/124866
Migrate `min-global-align` and `no-alloc-shim` `run-make` tests to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
Please try:
try-job: aarch64-apple
try-job: test-various
try-job: armhf-gnu
try-job: aarch64-gnu
try-job: aarch64-gnu
Port `run-make/sysroot-crates-are-unstable` to rmake
I already have a more elaborate draft at #126231 that tries to port the underlying Python script to rmake, but there's no need for the removal of Makefiles to be held up on complex tasks like that, so this PR simply takes the trivial Makefile and converts it into a trivial rmake recipe.
Part of #121876.
r? ``@jieyouxu``
Record the correct target type when coercing fn items/closures to pointers
Self-explanatory. We were previously not recording the *target* type of a coercion as the output of an adjustment. This should remedy that.
We must also modify the function pointer casts in MIR typeck to use subtyping, since those broke since #118247.
r? lcnr
Explicitly specify type parameter on FromResidual for Option and ControlFlow.
~~Remove type parameter default `R = <Self as Try>::Residual` from `FromResidual`~~ _Specify default type parameter on `FromResidual` impls in the stdlib_ to work around https://github.com/rust-lang/rust/issues/99940 / https://github.com/rust-lang/rust/issues/87350 ~~as mentioned in https://github.com/rust-lang/rust/issues/84277#issuecomment-1773259264~~.
This does not completely fix the issue, but works around it for `Option` and `ControlFlow` specifically (`Result` does not have the issue since it already did not use the default parameter of `FromResidual`).
~~(Does this need an ACP or similar?)~~ ~~This probably needs at least an FCP since it changes the API described in [the RFC](https://github.com/rust-lang/rfcs/pull/3058). Not sure if T-lang, T-libs-api, T-libs, or some combination (The tracking issue is tagged T-lang, T-libs-api).~~ This probably doesn't need T-lang input, since it is not changing the API of `FromResidual` from the RFC? Maybe needs T-libs-api FCP?
Rollup of 7 pull requests
Successful merges:
- #122884 (Optimize integer `pow` by removing the exit branch)
- #127857 (Allow to customize `// TODO:` comment for deprecated safe autofix)
- #129034 (Add `#[must_use]` attribute to `Coroutine` trait)
- #129049 (compiletest: Don't panic on unknown JSON-like output lines)
- #129050 (Emit a warning instead of an error if `--generate-link-to-definition` is used with other output formats than HTML)
- #129056 (Fix one usage of target triple in bootstrap)
- #129058 (Add mw back to review rotation)
r? `@ghost`
`@rustbot` modify labels: rollup
Remove a no-longer-true assert
Fixes https://github.com/rust-lang/rust/issues/129009
The assert was simply no longer true. I thought my test suite was thorough but I had not noticed these `let`-specific diagnostics codepaths.
r? `@compiler-errors`
Migrate `remap-path-prefix-dwarf` `run-make` test to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
Possibly my proudest branch name yet.
try-job: aarch64-apple
try-job: armhf-gnu
try-job: test-various
try-job: x86_64-gnu-llvm-18
Emit a warning instead of an error if `--generate-link-to-definition` is used with other output formats than HTML
Fixes https://github.com/rust-lang/docs.rs/issues/2581.
It's a bit weird to emit an error in this case anyway, a warning is more than enough.
r? ``@notriddle``
Add `#[must_use]` attribute to `Coroutine` trait
[Coroutines tracking issue](https://github.com/rust-lang/rust/issues/43122)
Like closures (`FnOnce`, `AsyncFn`, etc.), coroutines are lazy and do nothing unless called (resumed). Closure traits like `FnOnce` have `#[must_use = "closures are lazy and do nothing unless called"]` to catch likely bugs for users of APIs that produce them. This PR adds such a `#[must_use]` attribute to `trait Coroutine`.
Allow to customize `// TODO:` comment for deprecated safe autofix
Relevant for the deprecation of `CommandExt::before_exit` in #125970.
Tracking:
- #124866
CFI: Move CFI ui tests to cfi directory
Move the CFI ui tests to the cfi directory and removes the cfi prefix from tests file names similarly to how the cfi codegen tests are organized.
Matthias Krüger