[CS] A couple of fixes for implicit callAsFunction #28519
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@swift-ci please test |
xedin
approved these changes
Dec 2, 2019
| auto memberLoc = getConstraintLocator( | ||
| outerLocator.withPathElement(ConstraintLocator::Member)); | ||
| // Add a `callAsFunction` member constraint, binding the member type to a | ||
| // type variable. | ||
| auto memberTy = createTypeVariable(memberLoc, /*options=*/0); | ||
| // TODO: Revisit this if `static func callAsFunction` is to be supported. | ||
| // Static member constraint requires `FunctionRefKind::DoubleApply`. | ||
| // TODO: Use a custom locator element to identify this member constraint | ||
| // instead of just pointing to the function expr. |
There was a problem hiding this comment.
Thanks for adding this, something that I mentioned in the original PR for this feature as would be useful.
dan-zheng
approved these changes
Dec 2, 2019
hamishknight
force-pushed
the
callee-as-function
branch
from
22b7ed0 to
ed11139
Compare
|
@swift-ci please test |
This checks whether a type supports being called via callAsFunction. A request is used in order to cache the result of this query.
Add a case to getCalleeLocator to return the appropriate locator for a call to an implicit callAsFunction member reference. Resolves SR-11386 & SR-11778.
Previously this hit an assertion in CSApply. While we could technically make it work, it's probably best not to allow it. Resolves SR-11829.
Rather than coercing the call arguments ourselves, just build the finished member reference for the callAsFunction method, and let finishApply do the rest. This allows us to deal with transformations such as IUO unwraps. Resolves SR-11881.
We still want the constraint system to try looking up a callAsFunction method even if it's inaccessible, as we'll be able to record a fix and emit a suitable diagnostic.
hamishknight
force-pushed
the
callee-as-function
branch
from
ed11139 to
2d7a088
Compare
|
Rebased to resolve a merge conflict @swift-ci please smoke test and merge |
This was referenced Dec 4, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Start resolving callees for an implicit call to
callAsFunctionby adding a case for it ingetCalleeLocator, which allows it to be used with default arguments and diagnosed with things like requirement failures.In addition, prevent callables from being used with
AnyObjectlookup, previously this hit an assert in CSApply, now we'll reject it with an error.Finally, tweak the CSApply logic for
callAsFunctionsuch that we apply all offinishApply's transforms to it, which handles things like IUO unwraps.Resolves SR-11386, SR-11778, SR-11829, and SR-11881.