Whe completing in parameter packs, we were calling `getParameterAt` with `Res.FuncDeclRef`. But the substitution map in `Res.FuncDeclRef` contained type variables that were allocated in the constraint system’s arena. And that arena had been freed when we call this from `deliverResults`.
The fix is to compute the optional parameters in advance in `sawSolutionImpl`
rdar://109093909
We previously asserted that for a call the function type had the same number of parameters as the declaration. But that’s not true for parameter packs anymore because the parameter pack will be exploded in the function type to account for passing multiple arguments to the pack.
To fix this, use `ConcreteDeclRef` instead of a `ValueDecl`, which has a substitution map and is able to account for the exploded parameter packs when accessed using `getParameterAt`.
rdar://100066716
Setting the interface type of a variable, just to reset it to a null type is actually really gross. But quite a few methods further down in the generation of code completion results (such as USR generation) need to get a variable’s type and passing them along in a separate map would be really invasive. So this seems like the least bad solution to me.
This eliminates a source of bugs if subclasses of `TypeCheckCompletionCallback` forget to call the superclass’s implementation of `sawSolution` from their overridden method.
This hooks up call argument position completion to the typeCheckForCodeCompletion API to generate completions from all the solutions the constraint solver produces (even those requiring fixes), rather than relying on a single solution being applied to the AST (if any).
Co-authored-by: Nathan Hawes <nathan.john.hawes@gmail.com>
