Rework support for async closures; allow them to return futures that borrow from the closure's captures
This PR implements a new lowering for async closures via `TyKind::CoroutineClosure` which handles the curious relationship between the closure and the coroutine that it returns.
I wrote up a bunch in [this hackmd](https://hackmd.io/`@compiler-errors/S1HvqQxca)` which will be copied to the dev guide after this PR lands, and hopefully left sufficient comments in the source code explaining why this change is as large as it is.
This also necessitates that they begin implementing the `AsyncFn`-family of traits, rather than the `Fn`-family of traits -- if you need `Fn` implementations, you should probably use the non-sugar `|| async {}` syntax instead.
Notably this PR does not yet implement `async Fn()` syntax sugar for bounds, but I expect to add those soon (**edit:** #120392). For now, users must use `AsyncFn()` traits directly, which necessitates adding the `async_fn_traits` feature gate as well. I will add this as a follow-up very soon.
r? oli-obk
This is based on top of #120322, but that PR is minimal.
That is, change `diagnostic_outside_of_impl` and
`untranslatable_diagnostic` from `allow` to `deny`, because more than
half of the compiler has be converted to use translated diagnostics.
This commit removes more `deny` attributes than it adds `allow`
attributes, which proves that this change is warranted.
That is, change `diagnostic_outside_of_impl` and
`untranslatable_diagnostic` from `allow` to `deny`, because more than
half of the compiler has be converted to use translated diagnostics.
This commit removes more `deny` attributes than it adds `allow`
attributes, which proves that this change is warranted.
All the other `emit`/`emit_diagnostic` methods were recently made
consuming (e.g. #119606), but this one wasn't. But it makes sense to.
Much of this is straightforward, and lots of `clone` calls are avoided.
There are a couple of tricky bits.
- `Emitter::primary_span_formatted` no longer takes a `Diagnostic` and
returns a pair. Instead it takes the two fields from `Diagnostic` that
it used (`span` and `suggestions`) as `&mut`, and modifies them. This
is necessary to avoid the cloning of `diag.children` in two emitters.
- `from_errors_diagnostic` is rearranged so various uses of `diag` occur
before the consuming `emit_diagnostic` call.
make matching on NaN a hard error, and remove the rest of illegal_floating_point_literal_pattern
These arms would never be hit anyway, so the pattern makes little sense. We have had a future-compat lint against float matches in general for a *long* time, so I hope we can get away with immediately making this a hard error.
This is part of implementing https://github.com/rust-lang/rfcs/pull/3535.
Closes https://github.com/rust-lang/rust/issues/41620 by removing the lint.
https://github.com/rust-lang/reference/pull/1456 updates the reference to match.
rustdoc: trait.impl, type.impl: sort impls to make it not depend on serialization order
Can be tested by running `cargo doc` with different rust versions on some crate and comparing `doc` folders: files in `trait.impl` and `type.impl` will sometimes have different order of impls.
Rollup of 8 pull requests
Successful merges:
- #120484 (Avoid ICE when is_val_statically_known is not of a supported type)
- #120516 (pattern_analysis: cleanup manual impls)
- #120517 (never patterns: It is correct to lower `!` to `_`.)
- #120523 (Improve `io::Read::read_buf_exact` error case)
- #120528 (Store SHOULD_CAPTURE as AtomicU8)
- #120529 (Update data layouts in custom target tests for LLVM 18)
- #120531 (Remove a bunch of `has_errors` checks that have no meaningful or the wrong effect)
- #120533 (Correct paths for hexagon-unknown-none-elf platform doc)
r? `@ghost`
`@rustbot` modify labels: rollup
Miri has used the `target/miri` subdirectory since 2021 to keep itself
separate from non-miri builds, so this should not be necessary.
See commit 6a18683d09
Since the items are no longer a sequence of steps to do in
order ("first, make sure that ..."), switch to an unordered list while
we're at it.
Closes#3289
CI: Use ninja on apple builders
This switches the apple builders to use ninja when building LLVM. My hope is that this should resolve the timeouts we have been experiencing since December. My theory is that something in the image update from [Dec 20](dec20a5272) is causing an issue with our build (or, perhaps more remotely, some [update to LLVM itself](https://github.com/rust-lang/rust/commits/master/src/llvm-project)).
The symptoms are that during the LLVM build it just hangs just before the install step. The last thing it prints is `[100%] Built target llvm-reduce` and then just hangs. Normally the next part should be `Install the project...` where it starts installing LLVM. I'm able to reproduce this without too much difficulty. I've been testing ninja, and it seems to be working better (however, my test isn't quite equivalent, since I'm getting sccache misses, and I can't update the S3 bucket).
Installing ninja takes about 7 to 10 seconds, so it shouldn't impact things. I can't determine if it will affect the overall build timing due to not being able to test with a warm S3 cache.
Correct paths for hexagon-unknown-none-elf platform doc
Update the library paths to correctly refer to libdemo{1,2}_hexagon and switch to the release build instead.
Update references to libstandalone to the specific G0/PIC archive instead.
Switch over to rustc's `tracing` crate instead of using our own `log` crate
disadvantage: to turn on debug/trace logging, you need a rustc built with it
advantage: sharing our logging scheme with rustc, so our logs get nested correctly.
Update the library paths to correctly refer to libdemo{1,2}_hexagon
and switch to the release build instead.
Update references to libstandalone to the specific G0/PIC archive instead.
rustdoc: Correctly handle attribute merge if this is a glob reexport
Fixes#120487.
The regression was introduced in https://github.com/rust-lang/rust/pull/113091. Only non-glob reexports should have been impacted.
cc `````@Nemo157`````
r? `````@notriddle`````
Don't hash lints differently to non-lints.
`Diagnostic::keys`, which is used for hashing and equating diagnostics, has a surprising behaviour: it ignores children, but only for lints. This was added in #88493 to fix some duplicated diagnostics, but it doesn't seem necessary any more.
This commit removes the special case and only four tests have changed output, with additional errors. And those additional errors aren't exact duplicates, they're just similar. For example, in src/tools/clippy/tests/ui/same_name_method.rs we currently have this error:
```
error: method's name is the same as an existing method in a trait
--> $DIR/same_name_method.rs:75:13
|
LL | fn foo() {}
| ^^^^^^^^^^^
|
note: existing `foo` defined here
--> $DIR/same_name_method.rs:79:9
|
LL | impl T1 for S {}
| ^^^^^^^^^^^^^^^^
```
and with this change we also get this error:
```
error: method's name is the same as an existing method in a trait
--> $DIR/same_name_method.rs:75:13
|
LL | fn foo() {}
| ^^^^^^^^^^^
|
note: existing `foo` defined here
--> $DIR/same_name_method.rs:81:9
|
LL | impl T2 for S {}
|
```
I think printing this second argument is reasonable, possibly even preferable to hiding it. And the other cases are similar.
r? `@estebank`
Bump Fuchsia, build tests, and use 8 core bots
- Build Fuchsia on 8 cores instead of 16
- Skip building cranelift for Fuchsia
- Bump Fuchsia (includes building tests)
This includes a change to the upstream build_fuchsia_from_rust_ci script that builds a minimal set of tests, to improve coverage on this builder. This would have caught https://github.com/rust-lang/rust-clippy/issues/11952 and #119593.
See prior discussion on #119400 about building on 8 cores instead of 16. This PR combines changes from that and #119399, plus clean up.
r? `@Mark-Simulacrum`
