about summary refs log tree commit diff
path: root/src/test/ui/impl-trait
AgeCommit message (Collapse)AuthorLines
2020-01-16When trait bounds are missing for return values, point at themEsteban Küber-2/+6
2020-01-16Elide E0308 errors in favor of E0746Esteban Küber-82/+10
When a type error involves a `dyn Trait` as the return type, do not emit the type error, as the "return type is not `Sized`" error will provide enough information to the user.
2020-01-16Account for diverging types in return `impl Trait`Esteban Küber-0/+5
2020-01-16Specific error for unsized `dyn Trait` return typeEsteban Küber-0/+222
Suggest `impl Trait` when possible, and `Box<dyn Trait>` otherwise.
2020-01-15wrap expr id into GeneratorInteriorTypeCausecsmoe-2/+2
2020-01-11Rollup merge of #68014 - estebank:unify-e0599, r=cramertjYuki Okushi-26/+26
Unify output of "variant not found" errors Fix #49566.
2020-01-10Rollup merge of #66463 - estebank:point-at-closure-and-opaque-types, r=CentrilMazdak Farrokhzad-0/+27
Point at opaque and closure type definitions in type errors Fixes #57266, fixes #67117.
2020-01-09Update testsVadim Petrochenkov-6/+42
2020-01-08Point at the def span of trait refs E0277Esteban Küber-0/+9
2020-01-08review commentsEsteban Küber-4/+10
2020-01-08Point at opaque and closure type definitions in type errorsEsteban Küber-0/+12
2020-01-08Unify output of "variant not found" errorsEsteban Küber-26/+26
2020-01-06Account for `type X = impl Trait;` in lifetime suggestionEsteban Küber-1/+1
2019-12-31Change wording for lifetime suggestion for opaque types from `constraint` to ↵Ohad Ravid-11/+11
`bound`
2019-12-30Suggest adding a lifetime constraint when opaque type is responsible for ↵Ohad Ravid-0/+32
"does not live long enough" error
2019-12-28Ignore i586-unknown-linux-gnu and i586-unknown-musl in testsEsteban Küber-4/+7
2019-12-06bless polonius output due to lacking the 'static special-casingRemy Rakic-0/+12
2019-11-24Fix opaque types resulting from projections in function signatureAaron Hill-0/+22
When we normalize the types in a function signature, we may end up resolving a projection to an opaque type (e.g. `Self::MyType` when we have `type MyType = impl SomeTrait`). When the projection is resolved, we will instantiate the generic parameters into fresh inference variables. While we do want to normalize projections to opaque types, we don't want to replace the explicit generic parameters (e.g. `T` in `impl MyTrait<T>`) with inference variables. We want the opaque type in the function signature to be eligible to be a defining use of that opaque type - adding inference variables prevents this, since the opaque type substs now appears to refer to some specific type, rather than a generic type. To resolve this issue, we inspect the opaque types in the function signature after normalization. Any inference variables in the substs are replaced with the corresponding generic parameter in the identity substs (e.g. `T` in `impl MyTrait<T>`). Note that normalization is the only way that we can end up with inference variables in opaque substs in a function signature - users have no way of getting inference variables into a function signature. Note that all of this refers to the opaque type (ty::Opaque) and its subst - *not* to the underlying type. Fixes #59342
2019-11-21Point at type in `let` assignment on type errorsEsteban Küber-2/+6
2019-11-21Auto merge of #66389 - estebank:type-err-labels, r=petrochenkovbors-37/+34
Specific labels when referring to "expected" and "found" types
2019-11-19Rollup merge of #66431 - Aaron1011:fix/opaque-type-infer, r=varkorMazdak Farrokhzad-62/+65
Fix 'type annotations needed' error with opaque types Related: #66426 This commit adds handling for opaque types during inference variable fallback. Type variables generated from the instantiation of opaque types now fallback to the opaque 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-18Auto merge of #58281 - mark-i-m:synthesis, r=estebankbors-0/+6
Add outlives suggestions for some lifetime errors This PR implements suggestion diagnostics for some lifetime mismatch errors. When the borrow checker finds that some lifetime 'a doesn't outlive some other lifetime 'b that it should outlive, then in addition to the current lifetime error, we also emit a suggestion for how to fix the problem by adding a bound: - If a and b are normal named regions, suggest to add the bound `'a: 'b` - If b is static, suggest to replace a with static - If b also needs to outlive a, they must be the same, so suggest unifying them We start with a simpler implementation that avoids diagnostic regression or implementation complexity: - We only makes suggestions for lifetimes the user can already name (eg not closure regions or elided regions) - For now, we only emit a help note, not an actually suggestion because it is significantly easier. Finally, there is one hack: it seems that implicit regions in async fn are given the name '_ incorrectly. To avoid suggesting '_: 'x, we simply filter out such lifetimes by name. For more info, see this internals thread: https://internals.rust-lang.org/t/mechanical-suggestions-for-some-borrow-checker-errors/9049/3 TL;DR Make suggestions to add a `where 'a: 'b` constraint for some lifetime errors. Details are in the paper linked from the internals thread above. r? @estebank TODO - [x] Clean up code - [x] Only make idiomatic suggestions - [x] don't suggest naming `&'a self` - [x] rather than `'a: 'static`, suggest replacing `'a` with `'static` - [x] rather than `'a: 'b, 'b: 'a`, suggest replacing `'a` with `'b` or vice versa - [x] Performance (maybe need a perf run when this is closer to the finish line?) - perf run was clean... - EDIT: perf run seems to only check non-error performance... How do we check that error performance didn't regress? - [x] Needs ui tests - [x] Integrate the `help` message into the main lifetime `error`
2019-11-18Surround types with backticks in type errorsEsteban Küber-16/+16
2019-11-18Remove E0308 note when primary label has all infoEsteban Küber-3/+0
2019-11-18Specific labels when referring to "expected" and "found" typesEsteban Küber-22/+22
2019-11-18Update test outputAaron Hill-57/+45
2019-11-18Fix 'type annotations needed' error with opaque typesAaron Hill-5/+20
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-16/+26
2019-11-13Rollup merge of #66186 - GuillaumeGomez:long-err-explanation-E0623, r=Dylan-DPCYuki Okushi-1/+2
Add long error explanation for E0623 Part of #61137. r? @Dylan-DPC
2019-11-08Rollup merge of #65785 - Centril:compat-to-error-2, r=oli-obkMazdak Farrokhzad-175/+36
Transition future compat lints to {ERROR, DENY} - Take 2 Follow up to https://github.com/rust-lang/rust/pull/63247 implementing https://github.com/rust-lang/rust/pull/63247#issuecomment-536295992. - `legacy_ctor_visibility` (ERROR) -- closes #39207 - `legacy_directory_ownership` (ERROR) -- closes #37872 - `safe_extern_static` (ERROR) -- closes #36247 - `parenthesized_params_in_types_and_modules` (ERROR) -- closes #42238 - `duplicate_macro_exports` (ERROR) - `nested_impl_trait` (ERROR) -- closes #59014 - `ill_formed_attribute_input` (DENY) -- transitions #57571 - `patterns_in_fns_without_body` (DENY) -- transitions #35203 r? @varkor cc @petrochenkov
2019-11-08Rollup merge of #66049 - RalfJung:missing-spans, r=alexcrichtonYuki Okushi-5/+4
consistent handling of missing sysroot spans Due to https://github.com/rust-lang/rust/issues/53081, sysroot spans (pointing to code in libcore/libstd/...) fails to print on some x86 runners. This consolidates the ignore directives for that and references the relevant issue. I also did that for the generated derive-error-span tests -- but there the script and the tests were not entirely in sync any more since https://github.com/rust-lang/rust/pull/64151. Cc @estebank @varkor
2019-11-07Rollup merge of #66087 - tmiasko:ui-mode, r=CentrilMazdak Farrokhzad-5/+5
Update some build-pass ui tests to use check-pass where applicable Helps with issue https://github.com/rust-lang/rust/issues/62277.
2019-11-07Update ui testsGuillaume Gomez-1/+2
2019-11-06Suggest missing item from `trait` in `impl`Esteban Küber-1/+1
2019-11-06nested_impl_trait -> errorMazdak Farrokhzad-175/+36
2019-11-04Use check-pass in ui tests where appropriateTomasz Miąsko-5/+5
2019-11-02consistent handling of missing sysroot spansRalf Jung-5/+4
2019-11-02Prettify mismatched types error message in a special caseDmitry Kadashev-4/+2
Type parameters are referenced in the error message after the previous few commits (using span label). But when the main error message already references the very same type parameter it becomes clumsy. Do not show the additional label in this case as per code review comment by @estebank. Also this contains a small style fix.
2019-11-02Update testsDmitry Kadashev-6/+17
Update the tests to reflect changes to how type mismatch errors are reported (two previous commits).
2019-10-27Rollup merge of #65855 - ObsidianMinor:extended_error/E0666, r=varkorMazdak Farrokhzad-1/+2
Add long error explaination for E0666 In the spirit of the month of spooks, here's a long explanation for E0666 for #61137.
2019-10-27Rollup merge of #65777 - matthewjasper:allow-impl-trait-expansion, r=davidtwcoMazdak Farrokhzad-24/+42
Don't ICE for completely unexpandable `impl Trait` types Save the resolution of these types (to themselves) to the typeck tables so that they will eventually reach E0720. closes #65561
2019-10-27update testsMark Mansi-0/+6
2019-10-26Add detailed explaination for E0666Sydney Acksman-1/+2
2019-10-26Rollup merge of #65773 - estebank:sugg-whitespace, r=CentrilMazdak Farrokhzad-0/+9
Increase spacing for suggestions in diagnostics Make the spacing between the code snippet and verbose structured suggestions consistent with note and help messages. r? @Centril
2019-10-25Apply suggestions from code reviewmatthewjasper-2/+2
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
2019-10-24Don't ICE for completely unexpandable `impl Trait` typesMatthew Jasper-24/+42
2019-10-24Increase spacing for suggestions in diagnosticsEsteban Küber-0/+9
Make the spacing between the code snippet and verbose structured suggestions consistent with note and help messages.
2019-10-24Changed APIT with explicit generic args span to specific arg spansSydney Acksman-4/+6
2019-10-21Rollup merge of #65614 - varkor:apit-explicit-generics, r=matthewjasperMazdak Farrokhzad-4/+4
Improve error message for APIT with explicit generic arguments This is disallowed with type or const generics. cc https://github.com/rust-lang/rust/issues/61410.
2019-10-20Improve error message for APIT with explicit generic parametersvarkor-4/+4
This is disallowed with type or const generics.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-04-28 15:16:32 +0000