about summary refs log tree commit diff
path: root/src/test/ui/impl-trait/where-allowed.rs
AgeCommit message (Collapse)AuthorLines
2023-01-11Move /src/test to /testsAlbert Larsan-250/+0
2022-10-25--blessMaybe Waffle-0/+1
2022-10-25Allow `impl Fn() -> impl Trait` in return positionMaybe Waffle-4/+2
This allows writing the following function signatures: ```rust fn f0() -> impl Fn() -> impl Trait; fn f3() -> &'static dyn Fn() -> impl Trait; ``` These signatures were already allowed for common traits and associated types, there is no reason why `Fn*` traits should be special in this regard.
2022-02-17fix impl trait message, bless testsMichael Goulet-41/+41
2022-02-17Add more information to `impl Trait` deny errorMichael Goulet-41/+41
2021-11-08Don't abort compilation after giving a lint errorJoshua Nelson-0/+1
The only reason to use `abort_if_errors` is when the program is so broken that either: 1. later passes get confused and ICE 2. any diagnostics from later passes would be noise This is never the case for lints, because the compiler has to be able to deal with `allow`-ed lints. So it can continue to lint and compile even if there are lint errors.
2021-07-19Improve impl trait disallowed context error textSantiago Pastorino-41/+41
2021-04-06forbid `impl Trait` in generic param defaultsSNCPlay42-4/+28
2020-09-26Call `type_of` for opaque types later in compilationMatthew Jasper-0/+2
This ensures that various wf checks have already been done before we typeck item bodies.
2019-11-18Fix 'type annotations needed' error with opaque typesAaron Hill-5/+0
Related: #66426 This commit adds handling for opaque types during inference variable fallback. Type variables generated from the instantiatino of opaque types now fallback to the opque type itself. Normally, the type variable for an instantiated opaque type is either unified with the concrete type, or with the opaque type itself (e.g when a function returns an opaque type by calling another function). However, it's possible for the type variable to be left completely unconstrained. This can occur in code like this: ```rust pub type Foo = impl Copy; fn produce() -> Option<Foo> { None } ``` Here, we'll instantatiate the `Foo` in `Option<Foo>` to a fresh type variable, but we will never unify it with anything due to the fact that we return a `None`. This results in the error message: `type annotations needed: cannot resolve `_: std::marker::Copy`` pointing at `pub type Foo = impl Copy`. This message is not only confusing, it's incorrect. When an opaque type inference variable is completely unconstrained, we can always fall back to using the opaque type itself. This effectively turns that particular use of the opaque type into a non-defining use, even if it appears in a defining scope.
2019-11-14TAIT: adjust testsMazdak Farrokhzad-0/+1
2019-09-24Remove blanket silencing of "type annotation needed" errorsEsteban Küber-2/+4
Remove blanket check for existence of other errors before emitting "type annotation needed" errors, and add some eager checks to avoid adding obligations when they refer to types that reference `[type error]` in order to reduce unneded errors.
2019-08-02Replace "existential" by "opaque"varkor-2/+2
2019-08-02Update syntax in existing testsvarkor-2/+4
2018-12-25Remove licensesMark Rousskov-10/+0
2018-09-25Added tests.Alexander Regueiro-1/+0
2018-08-27fix anotherMark Mansi-1/+1
2018-08-14Merged migrated compile-fail tests and ui tests. Fixes #46841.David Wood-0/+235