-
Notifications
You must be signed in to change notification settings - Fork 10.6k
[CS] Eagerly produce holes in a couple of places #85527
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -1126,10 +1126,12 @@ func rdar17170728() { | |
| // expected-error@-1 4 {{optional type 'Int?' cannot be used as a boolean; test for '!= nil' instead}} | ||
| } | ||
|
|
||
| // FIXME: Bad diagnostic, `Bool.Stride` is bogus, we shouldn't be suggesting | ||
| // `reduce(into:)`, and the actual problem is that Int cannot be used as a boolean | ||
| // condition. | ||
| let _ = [i, j, k].reduce(0 as Int?) { // expected-error {{missing argument label 'into:' in call}} | ||
| // expected-error@-1 {{cannot convert value of type 'Int?' to expected argument type '(inout (Bool, Bool) -> Bool?, Int?) throws -> ()'}} | ||
| $0 && $1 ? $0 + $1 : ($0 ? $0 : ($1 ? $1 : nil)) | ||
| // expected-error@-1 {{binary operator '+' cannot be applied to two 'Bool' operands}} | ||
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Missed the fact that the diagnostic changed here, this is because the extra check for hole in
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, this expression is very tricky to diagnose properly… |
||
| // expected-error@-1 {{binary operator '+' cannot be applied to operands of type 'Bool.Stride' and 'Bool'}} | ||
| } | ||
| } | ||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,4 +1,4 @@ | ||
| // {"kind":"typecheck","signature":"(anonymous namespace)::ConnectedComponents::unionSets(swift::TypeVariableType*, swift::TypeVariableType*)","signatureAssert":"Assertion failed: (validComponentCount > 0), function unionSets"} | ||
| // RUN: not --crash %target-swift-frontend -typecheck %s | ||
| // RUN: not %target-swift-frontend -typecheck %s | ||
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The underlying crashes here aren't really fixed, I've added some similar variants as part of #85407, and the fuzzer should hopefully pick up more cases for the rest |
||
| let b = ( c , d a { | ||
| e b | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,4 +1,4 @@ | ||
| // {"kind":"typecheck","signature":"swift::constraints::ConstraintGraph::computeConnectedComponents(llvm::ArrayRef<swift::TypeVariableType*>)","signatureAssert":"Assertion failed: (component != components.end()), function operator()"} | ||
| // RUN: not --crash %target-swift-frontend -typecheck %s | ||
| // RUN: not %target-swift-frontend -typecheck %s | ||
| let i = Array(... a { " ? \(i Array* )" } | ||
| , b 1 |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,3 +1,3 @@ | ||
| // {"kind":"typecheck","signature":"swift::PackType::getExpandedGenericArgs(llvm::ArrayRef<swift::GenericTypeParamType*>, llvm::ArrayRef<swift::Type>)","signatureAssert":"Assertion failed: (isa<To>(Val) && \"cast<Ty>() argument of incompatible type!\"), function cast"} | ||
| // RUN: not --crash %target-swift-frontend -typecheck %s | ||
| // RUN: not %target-swift-frontend -typecheck %s | ||
| struct a < each b typealias c<each d> = a<> c < e |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We didn't do this originally because sometimes it still helpful to wait and infer member type from the context to help avoid
_in diagnostics but that indeed leads to some unnecessary hole propagation. But we do want to be more aggressive with missing members so I think this is okay to try and see how it goes.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I think we ought to be able to handle those cases in
repairFailuresinstead