[CodeCompletion] Fix a crash when completing the call pattern of a function that takes a parameter pack #73042
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
Member
ahoppen
commented
Apr 16, 2024
ahoppen
commented
- Explanation: We were incorrectly inferring the contextual type of a function call pattern to be the result type of the function call instead of the type of the context in which the functions call was being used. This was causing a crash when completing a call pattern of a function that takes a parameter pack due to an unresolved type in the return type. Getting the information about the contextual type out of the constraint system turns out to be quite hard. This PR limits contextual type inference to two well-known scenarios, in which it is now correctly implemented: If the call that we suggest call patterns for is itself an argument to another function or if it is used in a place that has a contextual type in the constraint system (eg. a variable binding or a return statement).
- Scope: Completion of call patterns
- Risk: Low, only affects code completion scoring
- Testing: Added a regression test
- Issue: rdar://124166587
- Reviewer: @rintaro and @xedin on [CodeCompletion] Don’t report a call pattern as convertible if its result type doesn’t match #72568 and [CodeCompletion] Fix a crash when completing the call pattern of a function that takes a parameter pack #72570
…sult type doesn’t match To compute the expected type of a call pattern (which is the return type of the function if that call pattern is being used), we called `getTypeForCompletion` for the entire call, in the same way that we do for the code completion token. However, this pattern does not generally work. For the code completion token it worked because the code completion expression doesn’t have an inherent type and it inherits the type solely from its context. Calls, however, have an inherent return type and that type gets assigned as the `typeForCompletion`. Implement targeted checks for the two most common cases where an expected type exists: If the call that we suggest call patterns for is itself an argument to another function or if it is used in a place that has a contextual type in the constraint system (eg. a variable binding or a `return` statement). This means that we no longer return `Convertible` for call patterns in some more complex scenarios. But given that this information was computed based on incorrect results and that in those cases all call patterns had a `Convertible` type relation, I think that’s acceptable. Fixing this would require recording more information in the constraints system, which is out-of-scope for now.
…nction that takes a parameter pack
The issue here was that we inferred the contextual type of the `Mixer` call to be the following, inferred from the result type of the partial call to the initializer of `Mixer`
```
(bound_generic_struct_type decl="swift_ide_test.(file).Mixer@/Users/alex/src/swift/test/IDE/complete_parameter_pack_as_call_argument.swift:3:8"
(pack_type num_elements=1
(pack_expansion_type
(pattern=unresolved_type)
(count=unresolved_type))))
```
Technically, the contextual type that we should have here should be `Any` (from `print`) but getting that information out of the constraint system turns out to be quite hard. swiftlang#72568 makes some improvements in this area but in general the constraint system does not contain enough information to figure out the contextual type of an arbitrary expression.
The important thing right now is that the unresolved type in here trips the constraint system over when comparing types of code completion results with the contextual type. To prevent the crash for now, reset the expected call type if the computed type contains an unresolved type.
rdar://124166587
Co-authored-by: Pavel Yaskevich <[email protected]>
|
@swift-ci Please test |
bnbarham
approved these changes
Apr 16, 2024
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.