Commit Graph

507 Commits

Author SHA1 Message Date
Michael Goulet
8e344ae127 Suppress type param suggestion if encountering invalid const infer 2025-01-02 23:39:16 +00:00
Michael Goulet
6885ff4a7b Unconditionally lower generic_arg_infer 2025-01-02 23:39:16 +00:00
Michael Goulet
ed9a4cfdeb Make sure we check the future type is Sized in AsyncFn* 2024-12-31 00:46:46 +00:00
Michael Goulet
9bcd1dee95 Actually print all the relevant parts of a coroutine in verbose mode 2024-12-25 01:08:59 +00:00
bors
ed14192604 Auto merge of #134294 - matthiaskrgr:rollup-anh6io8, r=matthiaskrgr
Rollup of 8 pull requests

Successful merges:

 - #134252 (Fix `Path::is_absolute` on Hermit)
 - #134254 (Fix building `std` for Hermit after `c_char` change)
 - #134255 (Update includes in `/library/core/src/error.rs`.)
 - #134261 (Document the symbol Visibility enum)
 - #134262 (Arbitrary self types v2: adjust diagnostic.)
 - #134265 (Rename `ty_def_id` so people will stop using it by accident)
 - #134271 (Arbitrary self types v2: better feature gate test)
 - #134274 (Add check-pass test for `&raw`)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-12-14 06:44:05 +00:00
Matthias Krüger
2846699366
Rollup merge of #134181 - estebank:trim-render, r=oli-obk
Tweak multispan rendering to reduce output length

Consider comments and bare delimiters the same as an "empty line" for purposes of hiding rendered code output of long multispans. This results in more aggressive shortening of rendered output without losing too much context, specially in `*.stderr` tests that have "hidden" comments. We do that check not only on the first 4 lines of the multispan, but now also on the previous to last line as well.
2024-12-14 03:54:31 +01:00
Adrian Taylor
174dae607c Arbitrary self types v2: adjust diagnostic.
The recently landed PR to adjust arbitrary self types was a bit
overenthusiastic, advising folks to use the new Receiver trait even
before it's been stabilized. Revert to the older wording of the lint in
such cases.
2024-12-13 15:40:37 +00:00
bors
f4f0fafd0c Auto merge of #132706 - compiler-errors:async-closures, r=oli-obk
Stabilize async closures (RFC 3668)

# Async Closures Stabilization Report

This report proposes the stabilization of `#![feature(async_closure)]` ([RFC 3668](https://rust-lang.github.io/rfcs/3668-async-closures.html)). This is a long-awaited feature that increases the expressiveness of the Rust language and fills a pressing gap in the async ecosystem.

## Stabilization summary

* You can write async closures like `async || {}` which return futures that can borrow from their captures and can be higher-ranked in their argument lifetimes.
* You can express trait bounds for these async closures using the `AsyncFn` family of traits, analogous to the `Fn` family.

```rust
async fn takes_an_async_fn(f: impl AsyncFn(&str)) {
    futures::join(f("hello"), f("world")).await;
}

takes_an_async_fn(async |s| { other_fn(s).await }).await;
```

## Motivation

Without this feature, users hit two major obstacles when writing async code that uses closures and `Fn` trait bounds:

- The inability to express higher-ranked async function signatures.
- That closures cannot return futures that borrow from the closure captures.

That is, for the first, we cannot write:

```rust
// We cannot express higher-ranked async function signatures.
async fn f<Fut>(_: impl for<'a> Fn(&'a u8) -> Fut)
where
    Fut: Future<Output = ()>,
{ todo!() }

async fn main() {
    async fn g(_: &u8) { todo!() }
    f(g).await;
    //~^ ERROR mismatched types
    //~| ERROR one type is more general than the other
}
```

And for the second, we cannot write:

```rust
// Closures cannot return futures that borrow closure captures.
async fn f<Fut: Future<Output = ()>>(_: impl FnMut() -> Fut)
{ todo!() }

async fn main() {
    let mut xs = vec![];
    f(|| async {
        async fn g() -> u8 { todo!() }
        xs.push(g().await);
    });
    //~^ ERROR captured variable cannot escape `FnMut` closure body
}
```

Async closures provide a first-class solution to these problems.

For further background, please refer to the [motivation section](https://rust-lang.github.io/rfcs/3668-async-closures.html#motivation) of the RFC.

## Major design decisions since RFC

The RFC had left open the question of whether we would spell the bounds syntax for async closures...

```rust
// ...as this...
fn f() -> impl AsyncFn() -> u8 { todo!() }
// ...or as this:
fn f() -> impl async Fn() -> u8 { todo!() }
```

We've decided to spell this as `AsyncFn{,Mut,Once}`.

The `Fn` family of traits is special in many ways.  We had originally argued that, due to this specialness, that perhaps the `async Fn` syntax could be adopted without having to decide whether a general `async Trait` mechanism would ever be adopted.  However, concerns have been raised that we may not want to use `async Fn` syntax unless we would pursue more general trait modifiers.  Since there remain substantial open questions on those -- and we don't want to rush any design work there -- it makes sense to ship this needed feature using the `AsyncFn`-style bounds syntax.

Since we would, in no case, be shipping a generalized trait modifier system anytime soon, we'll be continuing to see `AsyncFoo` traits appear across the ecosystem regardless.  If we were to ever later ship some general mechanism, we could at that time manage the migration from `AsyncFn` to `async Fn`, just as we'd be enabling and managing the migration of many other traits.

Note that, as specified in RFC 3668, the details of the `AsyncFn*` traits are not exposed and they can only be named via the "parentheses sugar".  That is, we can write `T: AsyncFn() -> u8` but not `T: AsyncFn<Output = u8>`.

Unlike the `Fn` traits, we cannot project to the `Output` associated type of the `AsyncFn` traits.  That is, while we can write...

```rust
fn f<F: Fn() -> u8>(_: F::Output) {}
```

...we cannot write:

```rust
fn f<F: AsyncFn() -> u8>(_: F::Output) {}
//~^ ERROR
```

The choice of `AsyncFn{,Mut,Once}` bounds syntax obviates, for our purposes here, another question decided after that RFC, which was how to order bound modifiers such as `for<'a> async Fn()`.

Other than answering the open question in the RFC on syntax, nothing has changed about the design of this feature between RFC 3668 and this stabilization.

## What is stabilized

For those interested in the technical details, please see [the dev guide section](https://rustc-dev-guide.rust-lang.org/coroutine-closures.html) I authored.

#### Async closures

Other than in how they solve the problems described above, async closures act similarly to closures that return async blocks, and can have parts of their signatures specified:

```rust
// They can have arguments annotated with types:
let _ = async |_: u8| { todo!() };

// They can have their return types annotated:
let _ = async || -> u8 { todo!() };

// They can be higher-ranked:
let _ = async |_: &str| { todo!() };

// They can capture values by move:
let x = String::from("hello, world");
let _ = async move || do_something(&x).await };
```

When called, they return an anonymous future type corresponding to the (not-yet-executed) body of the closure. These can be awaited like any other future.

What distinguishes async closures is that, unlike closures that return async blocks, the futures returned from the async closure can capture state from the async closure. For example:

```rust
let vec: Vec<String> = vec![];

let closure = async || {
    vec.push(ready(String::from("")).await);
};
```

The async closure captures `vec` with some `&'closure mut Vec<String>` which lives until the closure is dropped. Every call to `closure()` returns a future which reborrows that mutable reference `&'call mut Vec<String>` which lives until the future is dropped (e.g. it is `await`ed).

As another example:

```rust
let string: String = "Hello, world".into();

let closure = async move || {
    ready(&string).await;
};
```

The closure is marked with `move`, which means it takes ownership of the string by *value*. The future that is returned by calling `closure()` returns a future which borrows a reference `&'call String` which lives until the future is dropped (e.g. it is `await`ed).

#### Async fn trait family

To support the lending capability of async closures, and to provide a first-class way to express higher-ranked async closures, we introduce the `AsyncFn*` family of traits. See the [corresponding section](https://rust-lang.github.io/rfcs/3668-async-closures.html#asyncfn) of the RFC.

We stabilize naming `AsyncFn*` via the "parenthesized sugar" syntax that normal `Fn*` traits can be named. The `AsyncFn*` trait can be used anywhere a `Fn*` trait bound is allowed, such as:

```rust
/// In return-position impl trait:
fn closure() -> impl AsyncFn() { async || {} }

/// In trait bounds:
trait Foo<F>: Sized
where
    F: AsyncFn()
{
    fn new(f: F) -> Self;
}

/// in GATs:
trait Gat {
    type AsyncHasher<T>: AsyncFn(T) -> i32;
}
```

Other than using them in trait bounds, the definitions of these traits are not directly observable, but certain aspects of their behavior can be indirectly observed such as the fact that:

* `AsyncFn::async_call` and `AsyncFnMut::async_call_mut` return a future which is *lending*, and therefore borrows the `&self` lifetime of the callee.

```rust
fn by_ref_call(c: impl AsyncFn()) {
    let fut = c();
    drop(c);
    //   ^ Cannot drop `c` since it is borrowed by `fut`.
}
```

* `AsyncFnOnce::async_call_once` returns a future that takes ownership of the callee.

```rust
fn by_ref_call(c: impl AsyncFnOnce()) {
    let fut = c();
    let _ = c();
    //      ^ Cannot call `c` since calling it takes ownership the callee.
}
```

* All currently-stable callable types (i.e., closures, function items, function pointers, and `dyn Fn*` trait objects) automatically implement `AsyncFn*() -> T` if they implement `Fn*() -> Fut` for some output type `Fut`, and `Fut` implements `Future<Output = T>`.
    * This is to make sure that `AsyncFn*()` trait bounds have maximum compatibility with existing callable types which return futures, such as async function items and closures which return boxed futures.
    * For now, this only works currently for *concrete* callable types -- for example, a argument-position impl trait like `impl Fn() -> impl Future<Output = ()>` does not implement `AsyncFn()`, due to the fact that a `AsyncFn`-if-`Fn` blanket impl does not exist in reality. This may be relaxed in the future. Users can work around this by wrapping their type in an async closure and calling it. I expect this to not matter much in practice, as users are encouraged to write `AsyncFn` bounds directly.

```rust
fn is_async_fn(_: impl AsyncFn(&str)) {}

async fn async_fn_item(s: &str) { todo!() }
is_async_fn(s);
// ^^^ This works.

fn generic(f: impl Fn() -> impl Future<Output = ()>) {
    is_async_fn(f);
    // ^^^ This does not work (yet).
}
```

#### The by-move future

When async closures are called with `AsyncFn`/`AsyncFnMut`, they return a coroutine that borrows from the closure. However, when they are called via `AsyncFnOnce`, we consume that closure, and cannot return a coroutine that borrows from data that is now dropped.

To work around around this limitation, we synthesize a separate future type for calling the async closure via `AsyncFnOnce`.

This future executes identically to the by-ref future returned from calling the async closure, except for the fact that it has a different set of captures, since we must *move* the captures from the parent async into the child future.

#### Interactions between async closures and the `Fn*` family of traits

Async closures always implement `FnOnce`, since they always can be called once. They may also implement `Fn` or `FnMut` if their body is compatible with the calling mode (i.e. if they do not mutate their captures, or they do not capture their captures, respectively) and if the future returned by the async closure is not *lending*.

```rust
let id = String::new();

let mapped: Vec</* impl Future */> =
    [/* elements */]
    .into_iter()
    // `Iterator::map` takes an `impl FnMut`
    .map(async |element| {
        do_something(&id, element).await;
    })
    .collect();
```

See [the dev guide](https://rustc-dev-guide.rust-lang.org/coroutine-closures.html#follow-up-when-do-async-closures-implement-the-regular-fn-traits) for a detailed explanation for the situations where this may not be possible due to the lending nature of async closures.

#### Other notable features of async closures shared with synchronous closures

* Async closures are `Copy` and/or `Clone` if their captures are `Copy`/`Clone`.
* Async closures do closure signature inference: If an async closure is passed to a function with a `AsyncFn` or `Fn` trait bound, we can eagerly infer the argument types of the closure. More details are provided in [the dev guide](https://rustc-dev-guide.rust-lang.org/coroutine-closures.html#closure-signature-inference).

#### Lints

This PR also stabilizes the `CLOSURE_RETURNING_ASYNC_BLOCK` lint as an `allow` lint. This lints on "old-style" async closures:

```rust
#![warn(closure_returning_async_block)]
let c = |x: &str| async {};
```

We should encourage users to use `async || {}` where possible. This lint remains `allow` and may be refined in the future because it has a few false positives (namely, see: "Where do we expect rewriting `|| async {}` into `async || {}` to fail?")

An alternative that could be made at the time of stabilization is to put this lint behind another gate, so we can decide to stabilize it later.

## What isn't stabilized (aka, potential future work)

#### `async Fn*()` bound syntax

We decided to stabilize async closures without the `async Fn*()` bound modifier syntax. The general direction of this syntax and how it fits is still being considered by T-lang (e.g. in [RFC 3710](https://github.com/rust-lang/rfcs/pull/3710)).

#### Naming the futures returned by async closures

This stabilization PR does not provide a way of naming the futures returned by calling `AsyncFn*`.

Exposing a stable way to refer to these futures is important for building async-closure-aware combinators, and will be an important future step.

#### Return type notation-style bounds for async closures

The RFC described an RTN-like syntax for putting bounds on the future returned by an async closure:

```rust
async fn foo(x: F) -> Result<()>
where
    F: AsyncFn(&str) -> Result<()>,
    // The future from calling `F` is `Send` and `'static`.
    F(..): Send + 'static,
{}
```

This stabilization PR does not stabilize that syntax yet, which remains unimplemented (though will be soon).

#### `dyn AsyncFn*()`

`AsyncFn*` are not dyn-compatible yet. This will likely be implemented in the future along with the dyn-compatibility of async fn in trait, since the same issue (dealing with the future returned by a call) applies there.

## Tests

Tests exist for this feature in [`tests/ui/async-await/async-closures`](5b54286640/tests/ui/async-await/async-closures).

<details>
    <summary>A selected set of tests:</summary>

* Lending behavior of async closures
    * `tests/ui/async-await/async-closures/mutate.rs`
    * `tests/ui/async-await/async-closures/captures.rs`
    * `tests/ui/async-await/async-closures/precise-captures.rs`
    * `tests/ui/async-await/async-closures/no-borrow-from-env.rs`
* Async closures may be higher-ranked
    * `tests/ui/async-await/async-closures/higher-ranked.rs`
    * `tests/ui/async-await/async-closures/higher-ranked-return.rs`
* Async closures may implement `Fn*` traits
    * `tests/ui/async-await/async-closures/is-fn.rs`
    * `tests/ui/async-await/async-closures/implements-fnmut.rs`
* Async closures may be cloned
    * `tests/ui/async-await/async-closures/clone-closure.rs`
* Ownership of the upvars when `AsyncFnOnce` is called
    * `tests/ui/async-await/async-closures/drop.rs`
    * `tests/ui/async-await/async-closures/move-is-async-fn.rs`
    * `tests/ui/async-await/async-closures/force-move-due-to-inferred-kind.rs`
    * `tests/ui/async-await/async-closures/force-move-due-to-actually-fnonce.rs`
* Closure signature inference
    * `tests/ui/async-await/async-closures/signature-deduction.rs`
    * `tests/ui/async-await/async-closures/sig-from-bare-fn.rs`
    * `tests/ui/async-await/async-closures/signature-inference-from-two-part-bound.rs`

</details>

## Remaining bugs and open issues

* https://github.com/rust-lang/rust/issues/120694 tracks moving onto more general `LendingFn*` traits. No action needed, since it's not observable.
* https://github.com/rust-lang/rust/issues/124020 - Polymorphization ICE. Polymorphization needs to be heavily reworked. No action needed.
* https://github.com/rust-lang/rust/issues/127227 - Tracking reworking the way that rustdoc re-sugars bounds.
    * The part relevant to to `AsyncFn` is fixed by https://github.com/rust-lang/rust/pull/132697.

## Where do we expect rewriting `|| async {}` into `async || {}` to fail?

* Fn pointer coercions
    * Currently, it is not possible to coerce an async closure to an fn pointer like regular closures can be. This functionality may be implemented in the future.
```rust
let x: fn() -> _ = async || {};
```
* Argument capture
    * Like async functions, async closures always capture their input arguments. This is in contrast to something like `|t: T| async {}`, which doesn't capture `t` unless it is used in the async block. This may affect the `Send`-ness of the future or affect its outlives.
```rust
fn needs_send_future(_: impl Fn(NotSendArg) -> Fut)
where
    Fut: Future<Output = ()>,
{}

needs_send_future(async |_| {});
```

## History

#### Important feature history

- https://github.com/rust-lang/rust/pull/51580
- https://github.com/rust-lang/rust/pull/62292
- https://github.com/rust-lang/rust/pull/120361
- https://github.com/rust-lang/rust/pull/120712
- https://github.com/rust-lang/rust/pull/121857
- https://github.com/rust-lang/rust/pull/123660
- https://github.com/rust-lang/rust/pull/125259
- https://github.com/rust-lang/rust/pull/128506
- https://github.com/rust-lang/rust/pull/127482

## Acknowledgements

Thanks to `@oli-obk` for reviewing the bulk of the work for this feature. Thanks to `@nikomatsakis` for his design blog posts which generated interest for this feature, `@traviscross` for feedback and additions to this stabilization report. All errors are my own.

r? `@ghost`
2024-12-13 00:37:51 +00:00
Michael Goulet
c605c84be8 Stabilize async closures 2024-12-13 00:04:56 +00:00
Esteban Küber
49a22a4245 Filter empty lines, comments and delimiters from previous to last multiline span rendering 2024-12-12 23:36:27 +00:00
Esteban Küber
65a54a7f27 Tweak multispan rendering
Consider comments and bare delimiters the same as an "empty line" for purposes of hiding rendered code output of long multispans. This results in more aggressive shortening of rendered output without losing too much context, specially in `*.stderr` tests that have "hidden" comments.
2024-12-12 23:36:27 +00:00
bors
915e7eb9b9 Auto merge of #132961 - adetaylor:arbitrary-self-types-the-big-bit, r=compiler-errors,wesleywiser
Arbitrary self types v2: main compiler changes

This is the main PR in a series of PRs related to Arbitrary Self Types v2, tracked in #44874. Specifically this is step 7 of the plan [described here](https://github.com/rust-lang/rust/issues/44874#issuecomment-2122179688), for [RFC 3519](https://github.com/rust-lang/rfcs/pull/3519).

Overall this PR:
* Switches from the `Deref` trait to the new `Receiver` trait when the unstable `arbitrary_self_types` feature is enabled (the simple bit)
* Introduces new algorithms to spot "shadowing"; that is, the case where a newly-added method in an outer smart pointer might end up overriding a pre-existing method in the pointee (the complex bit). Most of this bit was explored in [this earlier perf-testing PR](https://github.com/rust-lang/rust/pull/127812#issuecomment-2236911900).
* Lots of tests

This should not break compatibility for:
* Stable users, where it should have no effect
* Users of the existing `arbitrary_self_types` feature (because we implement `Receiver` for `T: Deref`) _unless_ those folks have added methods which may shadow methods in inner types, which we no longer want to allow

Subsequent PRs will add better diagnostics.

It's probably easiest to review this commit-by-commit.

r? `@wesleywiser`
2024-12-12 21:40:39 +00:00
Adrian Taylor
e75660dad3 Arbitrary self types v2: use Receiver trait
In this new version of Arbitrary Self Types, we no longer use the Deref trait
exclusively when working out which self types are valid. Instead, we follow a
chain of Receiver traits. This enables methods to be called on smart pointer
types which fundamentally cannot support Deref (for instance because they are
wrappers for pointers that don't follow Rust's aliasing rules).

This includes:
* Changes to tests appropriately
* New tests for:
  * The basics of the feature
  * Ensuring lifetime elision works properly
  * Generic Receivers
  * A copy of the method subst test enhanced with Receiver

This is really the heart of the 'arbitrary self types v2' feature, and
is the most critical commit in the current PR.

Subsequent commits are focused on:
* Detecting "shadowing" problems, where a smart pointer type can hide
  methods in the pointee.
* Diagnostics and cleanup.

Naming: in this commit, the "Autoderef" type is modified so that it no
longer solely focuses on the "Deref" trait, but can now consider the
"Receiver" trait instead. Should it be renamed, to something like
"TraitFollower"? This was considered, but rejected, because
* even in the Receiver case, it still considers built-in derefs
* the name Autoderef is short and snappy.
2024-12-11 11:59:12 +00:00
Michael Goulet
a7fa4cbcb4 Implement projection and shim for AFIDT 2024-12-10 16:52:20 +00:00
León Orell Valerian Liehr
193a95d30b
Rollup merge of #134017 - compiler-errors:call-once-deduction, r=jieyouxu
Don't use `AsyncFnOnce::CallOnceFuture` bounds for signature deduction

We shouldn't be using `AsyncFnOnce::CallOnceFuture` projection bounds to deduce anything about the return type of an async closure, **only** `AsyncFnOnce::Output`. This was accidental b/c all we were looking at was the def id of the trait, rather than the projection. This PR fixes that.

This doesn't affect stable code, since `CallOnceFuture` bounds cannot be written on stable.

Fixes #134015
2024-12-10 13:51:10 +01:00
Michael Goulet
88669aed22 Don't use AsyncFnOnce::CallOnceFuture bounds for signature deduction 2024-12-08 00:01:21 +00:00
Esteban Küber
d860e5b088 Mention type parameter in more cases and don't suggest ~const bound already there 2024-12-07 21:37:13 +00:00
Esteban Küber
3f2a63a68b Use trait name instead of full constraint in suggestion message
```
help: consider restricting type parameter `T` with traits `Copy` and `Trait`
   |
LL | fn duplicate_custom<T: Copy + Trait>(t: S<T>) -> (S<T>, S<T>) {
   |                      ++++++++++++++
```

```
help: consider restricting type parameter `V` with trait `Copy`
   |
LL | fn index<'a, K, V: std::marker::Copy>(map: &'a HashMap<K, V>, k: K) -> &'a V {
   |                  +++++++++++++++++++
```
2024-12-07 21:29:58 +00:00
Esteban Küber
d13c34828e reword trait bound suggestion message to include the bounds 2024-12-07 21:26:20 +00:00
Eric Holk
72ce1ab42f
Stabilize noop_waker
Co-authored-by: zachs18 <8355914+zachs18@users.noreply.github.com>
2024-12-05 14:14:17 -08:00
Michael Goulet
59e3e8934e Gate async fn trait bound modifier on async_trait_bounds 2024-12-02 16:50:44 +00:00
Michael Goulet
a6f2f00de8 Move tests back to using AsyncFn 2024-12-02 16:49:59 +00:00
Michael Goulet
fa7449d130 Do not create trait object type if missing associated types 2024-11-30 17:05:47 +00:00
bors
a2545fd6fc Auto merge of #133540 - ehuss:compiletest-proc-macro, r=jieyouxu
Compiletest: add proc-macro header

This adds a `proc-macro` header to simplify using proc-macros, and to reduce boilerplate. This header works similar to the `aux-build` header where you pass a path for a proc-macro to be built.

This allows the `force-host`, `no-prefer-dynamic` headers, and `crate_type` attribute to be removed. Additionally it uses `--extern` like `aux_crate` (allows implicit `extern crate` in 2018) and `--extern proc_macro` (to place in the prelude in 2018).

~~This also includes a secondary change which defaults the edition of proc-macros to 2024. This further reduces boilerplate (removing `extern crate proc_macro;`), and allows using modern Rust syntax. I was a little on the fence including this. I personally prefer it, but I can imagine it might be confusing to others.~~ EDIT: Removed

Some tests were changed so that when there is a chain of dependencies A→B→C, that the `@ proc-macro` is placed in `B` instead of `A` so that the `--extern` flag works correctly (previously it depended on `-L` to find `C`). I think this is better to make the dependencies more explicit. None of these tests looked like the were actually testing this behavior.

There is one test that had an unexplained output change: `tests/ui/macros/same-sequence-span.rs`. I do not know why it changed, but it didn't look like it was particularly important. Perhaps there was a normalization issue?

This is currently not compatible with the rustdoc `build-aux-docs` header. It can probably be fixed, I'm just not feeling motivated to do that right now.

### Implementation steps

- [x] Document this new behavior in rustc-dev-guide once we figure out the specifics. https://github.com/rust-lang/rustc-dev-guide/pull/2149
2024-11-28 19:00:58 +00:00
Guillaume Gomez
bda2851826
Rollup merge of #133358 - compiler-errors:pin-coerce, r=eholk
Don't type error if we fail to coerce `Pin<T>` because it doesnt contain a ref

Fixes https://github.com/rust-lang/rust/issues/133222. Also moves some tests into a directory for better bookkeeping.

r? eholk or re-roll
2024-11-28 12:06:00 +01:00
Eric Huss
f94142b366 Update tests to use new proc-macro header 2024-11-27 07:18:25 -08:00
Michael Goulet
d26e29ff3a Tweak parameter mismatch explanation to not say unknown 2024-11-25 03:04:07 +00:00
Michael Goulet
2a94e1c2e0
Rollup merge of #132911 - compiler-errors:async-fn-sugar, r=fmease
Pretty print async fn sugar in opaques and trait bounds

sudo r? fmease
2024-11-22 21:07:39 -05:00
Michael Goulet
9455373d20 Don't type error if we fail to coerce Pin because it doesnt contain a ref 2024-11-23 01:41:18 +00:00
Michael Goulet
dd920fa31d Move pin ergonomics tests 2024-11-23 01:41:18 +00:00
Eric Huss
31c9222639 Stabilize the 2024 edition 2024-11-22 11:12:15 -08:00
Michael Goulet
4c53ad5f24 Pretty print AsyncFn traits too 2024-11-22 16:55:28 +00:00
Michael Goulet
97dfe8b871 Manually register some bounds for a better span 2024-11-08 04:56:08 +00:00
Michael Goulet
e4c1a0016c Get rid of check_opaque_type_well_formed 2024-11-08 03:46:27 +00:00
dianne
d7d6238b23 use backticks instead of single quotes when reporting "use of unstable library feature"
This is consistent with all other diagnostics I could find containing
features and enables the use of `DiagSymbolList` for generalizing
diagnostics for unstable library features to multiple features.
2024-11-03 13:55:52 -08:00
bors
b3f75cc872 Auto merge of #132147 - estebank:long-types-2, r=davidtwco
Tweak E0277 output when a candidate is available

*Follow up to #132086.*

Go from

```
error[E0277]: the trait bound `Then<Ignored<chumsky::combinator::Filter<chumsky::primitive::Any<&str, chumsky::extra::Full<EmptyErr, (), ()>>, {closure@src/main.rs:9:17: 9:27}>, char>, chumsky::combinator::Map<impl CSTParser<'a, O>, O, {closure@src/main.rs:11:24: 11:27}>, (), (), chumsky::extra::Full<EmptyErr, (), ()>>: CSTParser<'a>` is not satisfied
 --> src/main.rs:7:50
  |
7 | fn leaf<'a, O>(parser: impl CSTParser<'a, O>) -> impl CSTParser<'a, ()> {
  |                                                  ^^^^^^^^^^^^^^^^^^^^^^ the trait `chumsky::private::ParserSealed<'_, &str, (), chumsky::extra::Full<EmptyErr, (), ()>>` is not implemented for `Then<Ignored<Filter<Any<&str, ...>, ...>, ...>, ..., ..., ..., ...>`, which is required by `Then<Ignored<chumsky::combinator::Filter<chumsky::primitive::Any<&str, chumsky::extra::Full<EmptyErr, (), ()>>, {closure@src/main.rs:9:17: 9:27}>, char>, chumsky::combinator::Map<impl CSTParser<'a, O>, O, {closure@src/main.rs:11:24: 11:27}>, (), (), chumsky::extra::Full<EmptyErr, (), ()>>: CSTParser<'a>`
  |
  = help: the trait `chumsky::private::ParserSealed<'_, &'a str, ((), ()), chumsky::extra::Full<EmptyErr, (), ()>>` is implemented for `Then<Ignored<chumsky::combinator::Filter<chumsky::primitive::Any<&str, chumsky::extra::Full<EmptyErr, (), ()>>, {closure@src/main.rs:9:17: 9:27}>, char>, chumsky::combinator::Map<impl CSTParser<'a, O>, O, {closure@src/main.rs:11:24: 11:27}>, (), (), chumsky::extra::Full<EmptyErr, (), ()>>`
  = help: for that trait implementation, expected `((), ())`, found `()`
  = note: required for `Then<Ignored<Filter<Any<&str, ...>, ...>, ...>, ..., ..., ..., ...>` to implement `Parser<'_, &str, ()>`
note: required for `Then<Ignored<Filter<Any<&str, ...>, ...>, ...>, ..., ..., ..., ...>` to implement `CSTParser<'a>`
 --> src/main.rs:5:16
  |
5 | impl<'a, O, T> CSTParser<'a, O> for T where T: Parser<'a, &'a str, O> {}
  |                ^^^^^^^^^^^^^^^^     ^          ---------------------- unsatisfied trait bound introduced here
  = note: the full name for the type has been written to '/home/gh-estebank/longlong/target/debug/deps/longlong-0008f9a4f2023b08.long-type-13239977239800463552.txt'
  = note: consider using `--verbose` to print the full type name to the console
  = note: the full name for the type has been written to '/home/gh-estebank/longlong/target/debug/deps/longlong-0008f9a4f2023b08.long-type-13239977239800463552.txt'
  = note: consider using `--verbose` to print the full type name to the console
```

to

```
error[E0277]: the trait bound `Then<Ignored<chumsky::combinator::Filter<chumsky::primitive::Any<&str, chumsky::extra::Full<EmptyErr, (), ()>>, {closure@src/main.rs:9:17: 9:27}>, char>, chumsky::combinator::Map<impl CSTParser<'a, O>, O, {closure@src/main.rs:11:24: 11:27}>, (), (), chumsky::extra::Full<EmptyErr, (), ()>>: CSTParser<'a>` is not satisfied
  --> src/main.rs:7:50
   |
7  | fn leaf<'a, O>(parser: impl CSTParser<'a, O>) -> impl CSTParser<'a, ()> {
   |                                                  ^^^^^^^^^^^^^^^^^^^^^^ unsatisfied trait bound
...
11 |     ws.then(parser.map(|_| ()))
   |     --------------------------- return type was inferred to be `Then<Ignored<..., ...>, ..., ..., ..., ...>` here
   |
   = help: the trait `ParserSealed<'_, &_, (), Full<_, _, _>>` is not implemented for `Then<Ignored<..., ...>, ..., ..., ..., ...>`
           but trait `ParserSealed<'_, &'a _, ((), ()), Full<_, _, _>>` is implemented for it
   = help: for that trait implementation, expected `((), ())`, found `()`
   = note: required for `Then<Ignored<..., ...>, ..., ..., ..., ...>` to implement `Parser<'_, &str, ()>`
note: required for `Then<Ignored<..., ...>, ..., ..., ..., ...>` to implement `CSTParser<'a>`
  --> src/main.rs:5:16
   |
5  | impl<'a, O, T> CSTParser<'a, O> for T where T: Parser<'a, &'a str, O> {}
   |                ^^^^^^^^^^^^^^^^     ^          ---------------------- unsatisfied trait bound introduced here
   = note: the full name for the type has been written to '/home/gh-estebank/longlong/target/debug/deps/longlong-df9d52be87eada65.long-type-1337037744507305372.txt'
   = note: consider using `--verbose` to print the full type name to the console
```

* Remove redundant wording
* Introduce trait diff highlighting logic and use it
* Fix incorrect "long type written to path" logic (can be split off)
* Point at tail expression in more cases in E0277
* Avoid long primary span labels in E0277 by moving them to a `help`

Fix #132013.

There are individual commits that can be their own PR. If the review load is too big, happy to split them off.
2024-11-02 20:22:49 +00:00
Michael Goulet
9e5e47fc32 Remove or fix some FIXME(async_closure) 2024-11-02 03:33:31 +00:00
Esteban Küber
1a0c502183 On long E0277 primary span label, move it to a help
Long span labels don't read well.
2024-11-02 03:08:04 +00:00
Esteban Küber
092ecca5b9 Point at tail expression on rpit E0277
```
error[E0277]: the trait bound `{gen block@$DIR/gen_block_is_coro.rs:7:5: 7:8}: Coroutine` is not satisfied
  --> $DIR/gen_block_is_coro.rs:6:13
   |
LL | fn foo() -> impl Coroutine<Yield = u32, Return = ()> {
   |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Coroutine` is not implemented for `{gen block@$DIR/gen_block_is_coro.rs:7:5: 7:8}`
LL |     gen { yield 42 }
   |     ---------------- return type was inferred to be `{gen block@$DIR/gen_block_is_coro.rs:7:5: 7:8}` here
```

The secondary span label is new.
2024-11-02 03:08:04 +00:00
Esteban Küber
5b54286640 Remove detail from label/note that is already available in other note
Remove the "which is required by `{root_obligation}`" post-script in
"the trait `X` is not implemented for `Y`" explanation in E0277. This
information is already conveyed in the notes explaining requirements,
making it redundant while making the text (particularly in labels)
harder to read.

```
error[E0277]: the trait bound `NotCopy: Copy` is not satisfied
  --> $DIR/wf-static-type.rs:10:13
   |
LL | static FOO: IsCopy<Option<NotCopy>> = IsCopy { t: None };
   |             ^^^^^^^^^^^^^^^^^^^^^^^ the trait `Copy` is not implemented for `NotCopy`
   |
   = note: required for `Option<NotCopy>` to implement `Copy`
note: required by a bound in `IsCopy`
  --> $DIR/wf-static-type.rs:7:17
   |
LL | struct IsCopy<T:Copy> { t: T }
   |                 ^^^^ required by this bound in `IsCopy`
```
vs the prior

```
error[E0277]: the trait bound `NotCopy: Copy` is not satisfied
  --> $DIR/wf-static-type.rs:10:13
   |
LL | static FOO: IsCopy<Option<NotCopy>> = IsCopy { t: None };
   |             ^^^^^^^^^^^^^^^^^^^^^^^ the trait `Copy` is not implemented for `NotCopy`, which is required by `Option<NotCopy>: Copy`
   |
   = note: required for `Option<NotCopy>` to implement `Copy`
note: required by a bound in `IsCopy`
  --> $DIR/wf-static-type.rs:7:17
   |
LL | struct IsCopy<T:Copy> { t: T }
   |                 ^^^^ required by this bound in `IsCopy`
```
2024-10-29 16:26:57 +00:00
Michael Goulet
d8dc31fd3d Consider param-env candidates even if they have errors 2024-10-24 01:48:44 +00:00
Matthias Krüger
457087ed29
Rollup merge of #131549 - compiler-errors:try-in-sync, r=spastorino
Add a note for `?` on a `impl Future<Output = Result<..>>` in sync function

It's confusing to `?` a future of a result in a sync function. We have a suggestion to `.await` it if we're in an async function, but not a sync function. Note that this is the case for sync functions, at least.

Let's be a bit more vague about a fix, since it's somewhat context dependent. For example, you could block on it, or you could make your function asynchronous. 🤷
2024-10-22 15:28:41 +02:00
Matthias Krüger
fb691b470a
Rollup merge of #130635 - eholk:pin-reborrow-sugar, r=compiler-errors
Add `&pin (mut|const) T` type position sugar

This adds parser support for `&pin mut T` and `&pin const T` references. These are desugared to `Pin<&mut T>` and `Pin<&T>` in the AST lowering phases.

This PR currently includes #130526 since that one is in the commit queue. Only the most recent commits (bd450027eb4a94b814a7dd9c0fa29102e6361149 and following) are new.

Tracking:

- #130494

r? `@compiler-errors`
2024-10-15 05:12:34 +02:00
Michael Goulet
c8b71ef3dd Also note for fields 2024-10-12 06:14:46 -04:00
Michael Goulet
5e8820caaa Add a note for ? on future in sync function 2024-10-12 06:14:45 -04:00
Matthias Krüger
fa3dff3e24
Rollup merge of #131475 - fmease:compiler-mv-obj-safe-dyn-compat-2, r=jieyouxu
Compiler & its UI tests: Rename remaining occurrences of "object safe" to "dyn compatible"

Follow-up to #130826.
Part of #130852.

1. 1st commit: Fix stupid oversights. Should've been part of #130826.
2. 2nd commit: Rename the unstable feature `object_safe_for_dispatch` to `dyn_compatible_for_dispatch`. Might not be worth the churn, you decide.
3. 3rd commit: Apply the renaming to all UI tests (contents and paths).
2024-10-10 22:00:50 +02:00
León Orell Valerian Liehr
20cebae312
UI tests: Rename "object safe" to "dyn compatible" 2024-10-10 01:13:29 +02:00
Eric Holk
ae698f8199
Add sugar for &pin (const|mut) types 2024-10-07 11:15:04 -07:00
bors
5a4ee43c38 Auto merge of #129244 - cjgillot:opaque-hir, r=compiler-errors
Make opaque types regular HIR nodes

Having opaque types as HIR owner introduces all sorts of complications. This PR proposes to make them regular HIR nodes instead.

I haven't gone through all the test changes yet, so there may be a few surprises.

Many thanks to `@camelid` for the first draft.
Fixes https://github.com/rust-lang/rust/issues/129023

Fixes #129099
Fixes #125843
Fixes #119716
Fixes #121422
2024-10-05 06:19:35 +00:00
Jubilee
68de7d11a9
Rollup merge of #130633 - eholk:pin-reborrow-self, r=compiler-errors
Add support for reborrowing pinned method receivers

This builds on #130526 to add pinned reborrowing for method receivers. This enables the folllowing examples to work:

```rust
#![feature(pin_ergonomics)]
#![allow(incomplete_features)]

use std::pin::Pin;

pub struct Foo;

impl Foo {
    fn foo(self: Pin<&mut Self>) {
    }

    fn baz(self: Pin<&Self>) {
    }
}

pub fn bar(x: Pin<&mut Foo>) {
    x.foo();
    x.foo();

    x.baz(); // Pin<&mut Foo> is downgraded to Pin<&Foo>
}

pub fn baaz(x: Pin<&Foo>) {
    x.baz();
    x.baz();
}
```

This PR includes the original one, which is currently in the commit queue, but the only code changes are in the latest commit (d3c53aaa5c6fcb1018c58d229bc5d92202fa6880).

#130494

r? `@compiler-errors`
2024-10-04 19:19:24 -07:00