-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[Sema] Build TRC for delayed functions bodies #39064
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
Conversation
We used to build the full TypeRefinementContext of a source file before parsing delayed function bodies. This can lead to availability checking errors in delayed function bodies as the TRCs are incomplete. Complete the TRC of each delayed function before type-checking them to fix this. rdar://82269657
@swift-ci Please smoke test |
// RUN: %target-swift-frontend -typecheck -dump-type-refinement-contexts %s -target x86_64-apple-macos10.12 | ||
// RUN: %target-swift-frontend -typecheck -dump-type-refinement-contexts %s -target x86_64-apple-macos10.12 -experimental-skip-non-inlinable-function-bodies | ||
// RUN: %target-swift-frontend -typecheck -dump-type-refinement-contexts %s -target x86_64-apple-macos10.12 -experimental-skip-non-inlinable-function-bodies-without-types | ||
// RUN: %target-swift-frontend -typecheck -dump-type-refinement-contexts %s -target x86_64-apple-macos10.12 -experimental-skip-all-function-bodies |
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.
Is it worth checking the dumped contexts to make sure they aren't built in the skip-all (for all) and skip-non-inlinable (for funcWithType
) cases?
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.
Why not, it's a somewhat reliable way to detect if those functions were type-checked or not. I've added this check as a new commit!
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.
Would it be possible to remove TypeChecker::getOrBuildTypeRefinementContext
as well? There's only a single call in TypeChecker::overApproximateAvailabilityAtLocation
and I believe that one can just assume it's built. getOrBuild
seems somewhat unsafe since it doesn't handle delayed functions.
Would the refinement context for a delayed Decl ever be needed while typechecking a different Decl? Ie. should we ensure all contexts have been built prior to doing any typechecking?
LGTM otherwise
@swift-ci Please smoke test |
I think |
The compiler builds the full TypeRefinementContext of a source file before parsing delayed function bodies. This can lead to availability checking errors in delayed function bodies as the TRCs are incomplete.
Make sure we complete the TRC of each delayed function before type-checking them.
rdar://82269657