[TypeChecker] Drop @autoclosure attribute from invalid parameters #22186
Conversation
|
@swift-ci please smoke test |
|
@swift-ci please test source compatibility |
|
Actually it looks like I don't even need to mess with flags if declaration is marked as invalid, going to update PR in a few minutes. |
|
@swift-ci please smoke test |
|
@swift-ci please test source compatibility |
| // At this point we actually don't know if that's valid to mark | ||
| // this parameter declaration as `autoclosure` because type has | ||
| // not been resolved yet - it should either be a function type | ||
| // or typealias with underlying function type. |
There was a problem hiding this comment.
Huh, does this fix rdar://problem/47550733 ?
There was a problem hiding this comment.
I think that must be something else because it's related to @escaping attribute.
| // this decision couldn't be made based on type representative | ||
| // alone because it may be later resolved into an invalid type. | ||
| if (decl->isAutoClosure()) | ||
| hadError |= !(Ty && Ty->is<FunctionType>()); |
There was a problem hiding this comment.
Can we pull the diagnostic and the hadError = true; closer together? It feels strange to have them separated like this.
There was a problem hiding this comment.
Currently diagnostic is produced by type resolver but I can definitely move it to validateParameterType, not sure how much work that would be though.
Maybe it would make sense to revisit diagnostics separately from this PR?
validation-test/compiler_crashers_2_fixed/0189-rdar47586626.swift
Outdated
Show resolved
Hide resolved
While forming/validating parameters make sure that the type is indeed a function type before marking it as `autoclosure` based on type representative attributes, because parser doesn't change attributes even after the error has been found and diagnosed. Resolves: rdar://problem/47586626
|
@swift-ci please smoke test |
|
@swift-ci please test source compatibility |
|
Are you guys okay with me merging this as is? (I'd like to keep it minimal so it could be cherry-picked to 5.0) |
While forming/validating parameters make sure that the type is indeed
a function type before marking it as
autoclosurebased on typerepresentative attributes, because parser doesn't change attributes
even after the error has been found and diagnosed.
Resolves: rdar://problem/47586626