Skip to content

Conversation

@hamishknight
Copy link
Contributor

Enforce that a PatternBindingDecl always shares the same DeclContext as any VarDecls it binds. Then change top level vars in script mode such that they are treated as local vars unless you add an access control keyword. The implementation is pretty hacked together and a lot more test cases need updating, but interested to see what the source compatibility impact is.

Previously we would allow these in Sema and diagnose them in SILGen,
but allowing them in Sema is unsound because it means the constraint
system ends up kicking interface type requests for declarations that
should be type-checked as part of the closure itself. Adjust the
name lookup logic to look through parent closures when detecting
invalid forward references.

For now we don't fallback to an outer result on encountering a
use-before-declaration to preserve the current behavior. I'm planning
on changing that in the next commit though.

rdar://74430478
If we encounter a variable declared after its use within a closure,
we can fallback to using an outer result if present. This matches the
behavior outside of a closure and generally seems more consistent with
the behavior we have if we also find an inner result.

rdar://163656720
This allows the query to be consistent both during type-checking and
after.
Bindings in closures must be type-checked together with the surrounding
closure, add an assertion to make sure we don't try this. Carve out
an exception for code completion and error cases which may still kick
lazy type-checking. We ought to eventually fix up all the error cases
cases though since they imply we're leaving bits of the AST
un-type-checked.
@hamishknight
Copy link
Contributor Author

Doubt this will have much coverage, but let's see

@swift-ci please test source compatibility

FileCheck was matching against its own CHECK lines in the diagnostic
output here so the test always succeeded. Convert to using the
diagnostic verifier now we have `-verify-additional-prefix`.
This is no longer experimental and is the default.
not even close to complete
@hamishknight
Copy link
Contributor Author

swiftlang/swift-driver#2051

@swift-ci please test source compatibility

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant