about summary refs log tree commit diff
path: root/tests/ui/async-await
AgeCommit message (Collapse)AuthorLines
2025-10-03Don't normalize higher-ranked assumptions if they're not usedMichael Goulet-0/+89
2025-10-02Auto merge of #147138 - jackh726:split-canonical-bound, r=lcnrbors-3/+28
Split Bound index into Canonical and Bound See [#t-types/trait-system-refactor > perf `async-closures/post-mono-higher-ranked-hang.rs`](https://rust-lang.zulipchat.com/#narrow/channel/364551-t-types.2Ftrait-system-refactor/topic/perf.20.60async-closures.2Fpost-mono-higher-ranked-hang.2Ers.60/with/541535613) for context Things compile and tests pass, but not sure if this actually solves the perf issue (edit: it does). Opening up this to do a perf (and maybe crater) run. r? lcnr
2025-09-30Split Bound into Canonical and Boundjackh726-3/+28
2025-09-28reword noteEsteban Küber-5/+5
2025-09-28Point at lifetime requirement origin in more casesEsteban Küber-4/+10
2025-09-28Point at fn bound that introduced lifetime obligationEsteban Küber-1/+70
``` error[E0597]: `c` does not live long enough --> $DIR/without-precise-captures-we-are-powerless.rs:19:20 | LL | fn simple<'a>(x: &'a i32) { | -- lifetime `'a` defined here ... LL | let c = async move || { println!("{}", *x); }; | - binding `c` declared here LL | outlives::<'a>(c()); | ---------------^--- | | | | | borrowed value does not live long enough | argument requires that `c` is borrowed for `'a` LL | outlives::<'a>(call_once(c)); LL | } | - `c` dropped here while still borrowed | note: requirement that `c` is borrowed for `'a` introduced here --> $DIR/without-precise-captures-we-are-powerless.rs:7:33 | LL | fn outlives<'a>(_: impl Sized + 'a) {} | ^^ ``` When encountering a `ConstraintCategory::Predicate` in a funtion call, point at the `Span` for that `Predicate` to explain where the lifetime obligation originates from.
2025-09-13Auto merge of #146394 - Enselic:debuginfo-level-tests-2, r=jieyouxubors-0/+4
ci: Increase `rust.debuginfo-level-tests` to `2` in `x86_64-gnu-debug` job Simply to increase the scope of the testing. Part of https://github.com/rust-lang/rust/issues/61117. cc rust-lang/rust#145967 and rust-lang/rust#146025 which prepared for this. And rust-lang/rust#144499 that set to level to `1` try-job: x86_64-gnu-debug
2025-09-12ci: Increase `rust.debuginfo-level-tests` to `2` in `x86_64-gnu-debug` jobMartin Nordholts-0/+4
Simply to increase the scope of the testing. Force debuginfo=0 for a handful of tests so that we can have CI prevent regressing on more tests.
2025-09-10Restore the test intention of several MBE trait bound modifier testsLeón Orell Valerian Liehr-12/+13
2025-09-01Auto merge of #143290 - azhogin:azhogin/link-pub-async-impls, r=oli-obkbors-2/+85
pub async fn impl is monomorphized when func itself is monomorphized Implentation coroutine (`func::{closure#0}`) is monomorphized, when func itself is monomorphized. Currently, when `pub async fn foo(..)` is exported from lib and used in several dependent crates, only 'header' function is monomorphized in the defining crate. 'header' function, returning coroutine object, is monomorphized, but the coroutine's poll function (which actually implements all the logic for the function) is not. In such situation, `func::{closure#0}` will be monomorphized in every dependency. This PR adds monomorphization for `func::{closure#0}` (coroutine poll function), when func itself is monomorphized. Simple test with one lib async function and ten dependent crates (executable) that use the function, shows 5-7% compilation time improvement (single-threaded).
2025-09-01pub async fn implementation coroutine (func::{closure#0}) is monomorphized, ↵Andrew Zhogin-2/+85
when func itself is monomorphized
2025-08-31suggest method name with maybe ty mismatchyukang-0/+5
2025-08-26fix: Add col separator before secondary messages with no sourceScott Schafer-0/+1
2025-08-22On E0277, point at type that doesn't implement boundEsteban Küber-13/+36
When encountering an unmet trait bound, point at local type that doesn't implement the trait: ``` error[E0277]: the trait bound `Bar<T>: Foo` is not satisfied --> $DIR/issue-64855.rs:9:19 | LL | pub struct Bar<T>(<Self as Foo>::Type) where Self: ; | ^^^^^^^^^^^^^^^^^^^ unsatisfied trait bound | help: the trait `Foo` is not implemented for `Bar<T>` --> $DIR/issue-64855.rs:9:1 | LL | pub struct Bar<T>(<Self as Foo>::Type) where Self: ; | ^^^^^^^^^^^^^^^^^ ```
2025-08-20diagnostics :3lcnr-25/+19
2025-08-20handle opaque types before region inferencelcnr-24/+26
2025-08-20Rollup merge of #145623 - compiler-errors:pretty-async-name, r=wesleywiserJacob Pratt-0/+18
Pretty print the name of an future from calling async closure Fixes https://github.com/rust-lang/rust/issues/145606 by introducing a way to customize the path rendering of async closures' futures in the pretty printer API.
2025-08-19Pretty print the name of an future from calling async closureMichael Goulet-0/+18
2025-08-13add testlcnr-0/+17
2025-08-11Rollup merge of #145194 - compiler-errors:coro-witness-re, r=lcnrStuart Cook-0/+14
Ignore coroutine witness type region args in auto trait confirmation ## The problem Consider code like: ``` async fn process<'a>() { Box::pin(process()).await; } fn require_send(_: impl Send) {} fn main() { require_send(process()); } ``` When proving that the coroutine `{coroutine@process}::<'?0>: Send`, we end up instantiating a nested goal `{witness@process}::<'?0>: Send` by synthesizing a witness type from the coroutine's args: Proving a coroutine witness type implements an auto trait requires looking up the coroutine's witness types. The witness types are a binder that look like `for<'r> { Pin<Box<{coroutine@process}::<'r>>> }`. We instantiate this binder with placeholders and prove `Send` on the witness types. This ends up eventually needing to prove something like `{coroutine@process}::<'!1>: Send`. Repeat this process, and we end up in an overflow during fulfillment, since fulfillment does not use freshening. This can be visualized with a trait stack that ends up looking like: * `{coroutine@process}::<'?0>: Send` * `{witness@process}::<'?0>: Send` * `Pin<Box<{coroutine@process}::<'!1>>>: Send` * `{coroutine@process}::<'!1>: Send` * ... * `{coroutine@process}::<'!2>: Send` * `{witness@process}::<'!2>: Send` * ... * overflow! The problem here specifically comes from the first step: synthesizing a witness type from the coroutine's args. ## Why wasn't this an issue before? Specifically, before 63f6845e570305a92eaf855897768617366164d6, this wasn't an issue because we were instead extracting the witness from the coroutine type itself. It turns out that given some `{coroutine@process}::<'?0>`, the witness type was actually something like `{witness@process}::<'erased>`! So why do we end up with a witness type with `'erased` in its args? This is due to the fact that opaque type inference erases all regions from the witness. This is actually explicitly part of opaque type inference -- changing this to actually visit the witness types actually replicates this overflow even with 63f6845e570305a92eaf855897768617366164d6 reverted: https://github.com/rust-lang/rust/blob/ca77504943887037504c7fc0b9bf06dab3910373/compiler/rustc_borrowck/src/type_check/opaque_types.rs#L303-L313 To better understand this difference and how it avoids a cycle, if you look at the trait stack before 63f6845e570305a92eaf855897768617366164d6, we end up with something like: * `{coroutine@process}::<'?0>: Send` * `{witness@process}::<'erased>: Send` **<-- THIS CHANGED** * `Pin<Box<{coroutine@process}::<'!1>>>: Send` * `{coroutine@process}::<'!1>: Send` * ... * `{coroutine@process}::<'erased>: Send` **<-- THIS CHANGED** * `{witness@process}::<'erased>: Send` **<-- THIS CHANGED** * coinductive cycle! :tada: ## So what's the fix? This hack replicates the behavior in opaque type inference to erase regions from the witness type, but instead erasing the regions during auto trait confirmation. This is kinda a hack, but is sound. It does not need to be replicated in the new trait solver, of course. --- I hope this explanation makes sense. We could beta backport this instead of the revert https://github.com/rust-lang/rust/pull/145193, but then I'd like to un-revert that on master in this PR along with landing this this hack. Thoughts? r? lcnr
2025-08-10Ignore coroutine witness type region args in auto trait confirmationMichael Goulet-0/+14
2025-08-08Add test for upvar breakageMichael Goulet-0/+55
2025-08-08Check coroutine upvars and in dtorck constraintMichael Goulet-0/+45
2025-08-06Print thread ID in panic message if thread name is unknownTrevor Gross-2/+2
`panic!` does not print any identifying information for threads that are unnamed. However, in many cases, the thread ID can be determined. This changes the panic message from something like this: thread '<unnamed>' panicked at src/main.rs:3:5: explicit panic To something like this: thread '<unnamed>' (0xff9bf) panicked at src/main.rs:3:5: explicit panic Stack overflow messages are updated as well. This change applies to both named and unnamed threads. The ID printed is the OS integer thread ID rather than the Rust thread ID, which should also be what debuggers print.
2025-07-31Remove the witness type from coroutine argsMichael Goulet-27/+3
2025-07-31Stall coroutines based off of ty::Coroutine, not ty::CoroutineWitnessMichael Goulet-2/+24
2025-07-31Rollup merge of #143672 - beepster4096:box_drop_flags_again, r=oli-obkStuart Cook-0/+255
Fix Box allocator drop elaboration New version of rust-lang/rust#131146. Clearing Box's drop flag after running its destructor can cause it to skip dropping its allocator, so just don't. Its cleared by the drop ladder code afterwards already. Unlike the last PR this also handles other types with destructors properly, in the event that we can have open drops on them in the future (by partial initialization or DerefMove or something). Finally, I also added tests for the interaction with async drop here but I discovered rust-lang/rust#143658, so one of the tests has a `knownbug` annotation. Not sure if it should be in this PR at all though. Fixes rust-lang/rust#131082 r? wesleywiser - prev. reviewer
2025-07-29add `nonpoison::mutex` implementationConnor Tsui-8/+8
Adds the equivalent `nonpoison` types to the `poison::mutex` module. These types and implementations are gated under the `nonpoison_mutex` feature gate. Also blesses the ui tests that now have a name conflicts (because these types no longer have unique names). The full path distinguishes the different types. Co-authored-by: Aandreba <aandreba@gmail.com> Co-authored-by: Trevor Gross <tmgross@umich.edu>
2025-07-26Rollup merge of #144356 - GuillaumeGomez:gcc-ignore-tests, r=jieyouxuTrevor Gross-4/+6
Add `ignore-backends` annotations in failing GCC backend ui tests Follow-up of https://github.com/rust-lang/rust/pull/144125. In the GCC backend, we don't support all ui tests yet and we have a list of tests we currently ignore available [here](https://github.com/rust-lang/rustc_codegen_gcc/blob/master/tests/failing-ui-tests.txt). This PR adds the `ignore-backends` annotations to the corresponding ui tests. The second commit is a fix to compiletest, complaining about `ignore-backends`. r? ```@jieyouxu```
2025-07-25async drop tests for boxbeepster4096-0/+255
2025-07-23Point at the type that doesn't impl `Clone` in more cases beyond closuresEsteban Küber-5/+7
2025-07-23Add `ignore-backends` annotations in failing GCC backend ui testsGuillaume Gomez-4/+6
2025-07-18Rollup merge of #143699 - compiler-errors:async-drop-fund, r=oli-obkMatthias Krüger-0/+45
Make `AsyncDrop` check that it's being implemented on a local ADT Fixes https://github.com/rust-lang/rust/issues/143691
2025-07-18Auto merge of #143545 - compiler-errors:coroutine-obl, r=oli-obkbors-11/+1218
`-Zhigher-ranked-assumptions`: Consider WF of coroutine witness when proving outlives assumptions ### TL;DR This PR introduces an unstable flag `-Zhigher-ranked-assumptions` which tests out a new algorithm for dealing with some of the higher-ranked outlives problems that come from auto trait bounds on coroutines. See: * rust-lang/rust#110338 While it doesn't fix all of the issues, it certainly fixed many of them, so I'd like to get this landed so people can test the flag on their own code. ### Background Consider, for example: ```rust use std::future::Future; trait Client { type Connecting<'a>: Future + Send where Self: 'a; fn connect(&self) -> Self::Connecting<'_>; } fn call_connect<C>(c: C) -> impl Future + Send where C: Client + Send + Sync, { async move { c.connect().await } } ``` Due to the fact that we erase the lifetimes in a coroutine, we can think of the interior type of the async block as something like: `exists<'r, 's> { C, &'r C, C::Connecting<'s> }`. The first field is the `c` we capture, the second is the auto-ref that we perform on the call to `.connect()`, and the third is the resulting future we're awaiting at the first and only await point. Note that every region is uniquified differently in the interior types. For the async block to be `Send`, we must prove that both of the interior types are `Send`. First, we have an `exists<'r, 's>` binder, which needs to be instantiated universally since we treat the regions in this binder as *unknown*[^exist]. This gives us two types: `{ &'!r C, C::Connecting<'!s> }`. Proving `&'!r C: Send` is easy due to a [`Send`](https://doc.rust-lang.org/nightly/std/marker/trait.Send.html#impl-Send-for-%26T) impl for references. Proving `C::Connecting<'!s>: Send` can only be done via the item bound, which then requires `C: '!s` to hold (due to the `where Self: 'a` on the associated type definition). Unfortunately, we don't know that `C: '!s` since we stripped away any relationship between the interior type and the param `C`. This leads to a bogus borrow checker error today! ### Approach Coroutine interiors are well-formed by virtue of them being borrow-checked, as long as their callers are invoking their parent functions in a well-formed way, then substitutions should also be well-formed. Therefore, in our example above, we should be able to deduce the assumption that `C: '!s` holds from the well-formedness of the interior type `C::Connecting<'!s>`. This PR introduces the notion of *coroutine assumptions*, which are the outlives assumptions that we can assume hold due to the well-formedness of a coroutine's interior types. These are computed alongside the coroutine types in the `CoroutineWitnessTypes` struct. When we instantiate the binder when proving an auto trait for a coroutine, we instantiate the `CoroutineWitnessTypes` and stash these newly instantiated assumptions in the region storage in the `InferCtxt`. Later on in lexical region resolution or MIR borrowck, we use these registered assumptions to discharge any placeholder outlives obligations that we would otherwise not be able to prove. ### How well does it work? I've added a ton of tests of different reported situations that users have shared on issues like rust-lang/rust#110338, and an (anecdotally) large number of those examples end up working straight out of the box! Some limitations are described below. ### How badly does it not work? The behavior today is quite rudimentary, since we currently discharge the placeholder assumptions pretty early in region resolution. This manifests itself as some limitations on the code that we accept. For example, `tests/ui/async-await/higher-ranked-auto-trait-11.rs` continues to fail. In that test, we must prove that a placeholder is equal to a universal for a param-env candidate to hold when proving an auto trait, e.g. `'!1 = 'a` is required to prove `T: Trait<'!1>` in a param-env that has `T: Trait<'a>`. Unfortunately, at that point in the MIR body, we only know that the placeholder is equal to some body-local existential NLL var `'?2`, which only gets equated to the universal `'a` when being stored into the return local later on in MIR borrowck. This could be fixed by integrating these assumptions into the type outlives machinery in a more first-class way, and delaying things to the end of MIR typeck when we know the full relationship between existential and universal NLL vars. Doing this integration today is quite difficult today. `tests/ui/async-await/higher-ranked-auto-trait-11.rs` fails because we don't compute the full transitive outlives relations between placeholders. In that test, we have in our region assumptions that some `'!1 = '!2` and `'!2 = '!3`, but we must prove `'!1 = '!3`. This can be fixed by computing the set of coroutine outlives assumptions in a more transitive way, or as I mentioned above, integrating these assumptions into the type outlives machinery in a more first-class way, since it's already responsible for the transitive outlives assumptions of universals. ### Moving forward I'm still quite happy with this implementation, and I'd like to land it for testing. I may work on overhauling both the way we compute these coroutine assumptions and also how we deal with the assumptions during (lexical/nll) region checking. But for now, I'd like to give users a chance to try out this new `-Zhigher-ranked-assumptions` flag to uncover more shortcomings. [^exist]: Instantiating this binder with infer regions would be incomplete, since we'd be asking for *some* instantiation of the interior types, not proving something for *all* instantiations of the interior types.
2025-07-17Eagerly unify coroutine witness in old solverMichael Goulet-2/+2
2025-07-15Add tests, some of them fail...Michael Goulet-0/+1206
2025-07-15Gate things properlyMichael Goulet-2/+64
2025-07-15Consider outlives assumptions when proving auto traits for coroutine interiorsMichael Goulet-63/+2
2025-07-10Remove uncessary parens in closure body with unused lintyukang-16/+0
2025-07-09Make AsyncDrop check that it's being implemented on a local ADTMichael Goulet-0/+45
2025-07-05Rename tests named with `mbe` to use `macro` insteadJosh Triplett-4/+4
Most macro tests use `macro` in the name, making it easy to find and run tests relevant to macros. However, a few use `mbe` instead. Rename those to say `macro`.
2025-07-04Rollup merge of #142440 - Kivooeo:tf14, r=tgross35Jubilee-0/+33
`tests/ui`: A New Order [14/N] > [!NOTE] > > Intermediate commits are intended to help review, but will be squashed prior to merge. Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895. r? `@jieyouxu`
2025-07-01cleaned up some testsKivooeo-2/+6
2025-07-01Give some UI tests more apropriate namesTrevor Gross-0/+29
Prepare for rework done by the rest of RUST-142440. Co-authored-by: Kivooeo <Kivooeo123@gmail.com>
2025-06-30Unconditionally run `check_item_type` on all itemsOli Scherer-8/+8
2025-06-27Report infer ty errors during hir ty loweringOli Scherer-3/+30
This centralizes the placeholder type error reporting in one location, but it also exposes the granularity at which we convert things from hir to ty more. E.g. previously infer types in where bounds were errored together with the function signature, but now they are independent.
2025-06-24Rollup merge of #135731 - frank-king:feature/pin-borrow, r=eholk,traviscrossJubilee-302/+0
Implement parsing of pinned borrows This PR implements part of #130494. EDIT: It introduces `&pin mut $place` and `&pin const $place` as sugars for `std::pin::pin!($place)` and its shared reference equivalent, except that `$place` will not be moved when borrowing. The borrow check will be in charge of enforcing places cannot be moved or mutably borrowed since being pinned till dropped. ### Implementation steps: - [x] parse the `&pin mut $place` and `&pin const $place` syntaxes - [ ] borrowck of `&pin mut|const` - [ ] support autoref of `&pin mut|const` when needed
2025-06-23compiletest: Improve diagnostics for line annotation mismatchesVadim Petrochenkov-2/+2
2025-06-18Rollup merge of #142606 - ↵Trevor Gross-0/+29
azhogin:azhogin/async-drop-without-sync-drop-error, r=oli-obk AsyncDrop trait without sync Drop generates an error When type implements `AsyncDrop` trait, it must also implement sync `Drop` trait to be used in sync context and unwinds. This PR adds error generation in such a case. Fixes: rust-lang/rust#140696
2025-06-18Rollup merge of #141610 - BoxyUwU:stabilize_generic_arg_infer, ↵Jakub Beránek-14/+2
r=lcnr,traviscross Stabilize `feature(generic_arg_infer)` Fixes rust-lang/rust#85077 r? lcnr cc ````@rust-lang/project-const-generics````