about summary refs log tree commit diff
path: root/src/test/ui/impl-trait
AgeCommit message (Collapse)AuthorLines
2020-02-19Tweak binding lifetime suggestion textEsteban Küber-2/+2
We already have a structured suggestion, but the wording made it seem like that wasn't the case. Fix #65286. r? @varkor
2020-02-14Fix and test nested impl TraitMatthew Jasper-0/+16
2020-02-14Update testsMatthew Jasper-19/+118
2020-02-14Handle equal regions in opaque type inferenceMatthew Jasper-0/+57
2020-02-14Update testsMatthew Jasper-46/+168
2020-02-14Call `is_freeze` less in unsafety-checkingMatthew Jasper-0/+32
This is to avoid cycles when calling `is_freeze` on an opaque type.
2020-02-14Explain a testMatthew Jasper-2/+9
2020-02-11Auto merge of #68929 - matprec:consistent-issue-references, r=Dylan-DPCbors-3/+3
Make issue references consistent Fixes https://github.com/rust-lang/rust/issues/62976 cc https://github.com/rust-lang/rust/pull/63008 r? @varkor because you reviewed the original pr
2020-02-09Auto merge of #67665 - Patryk27:master, r=zackmdavisbors-5/+10
Improve reporting errors and suggestions for trait bounds Fix #66802 - When printing errors for unsized function parameter, properly point at the parameter instead of function's body. - Improve `consider further restricting this bound` (and related) messages by separating human-oriented hints from the machine-oriented ones.
2020-02-09--bless --compare-mode=nllMatthias Prechtl-3/+3
2020-02-09Improve reporting errors and suggestions for trait boundsPatryk Wychowaniec-5/+10
2020-02-08review commentEsteban Küber-1/+1
2020-02-02Use more appropriate spans on object unsafe traits and provide structured ↵Esteban Küber-2/+8
suggestions when possible
2020-02-02Wording changes to object unsafe trait errorsEsteban Küber-2/+10
Stemming from the thread at https://twitter.com/indygreg/status/1223279056398929920
2020-02-02fix testEsteban Küber-4/+4
2020-02-02Rollup merge of #68760 - Tyg13:compile_fail_ui_test, r=CentrilMazdak Farrokhzad-5/+4
Issue error on `compile-fail` header in UI test Fixes #68732 r? @Centril
2020-02-02compiletest: error if `compile-fail` header in ui test.Tyler Lanphear-5/+4
2020-02-01Deduplicate generator interior typesJonas Schievink-2/+2
2020-01-24Apply `resolve_vars_if_possible` to returned types for more accurate suggestionsEsteban Küber-6/+6
2020-01-24Use more accurate return path spansEsteban Küber-25/+43
No longer suggest `Box::new(if foo { Type1 } else { Type2 })`, instead suggesting `if foo { Box::new(Type1) } else { Box::new(Type2) }`.
2020-01-23Account for `ty::Error` when suggesting `impl Trait` or `Box<dyn Trait>`Esteban Küber-2/+183
2020-01-16Account for object safety when suggesting `Box<dyn Trait>`Esteban Küber-2/+143
2020-01-16review commentsEsteban Küber-4/+11
2020-01-16review commentsEsteban Küber-0/+1
2020-01-16review commentsEsteban Küber-27/+13
2020-01-16Add E0746 explanation to the indexEsteban Küber-1/+1
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
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-26 08:24:18 +0000