[IDE] Two more preparation commits for solver-based cursor info

[ahoppen]

[IDE] Make isDynamicRef take a getType function (@bnbarham)

This allows isDynamicRef to work with types from a constraint system solution

---

[IDE] Move getSelectedOverloadInfo to be a function on Solution (@xedin)

We will need this for solver-based cursor info.

---

[Sema] Add a solution callback that is called when the constraint system produces a solution (@xedin)

When doing solver-based cursor info, we’ll type check the expression in question using a normal typeCheckASTNodeAtLoc call (not in code completion mode) and listen for any solutions that were produced during the type check.

[ahoppen]

@swift-ci Please smoke test

[bnbarham]

Not sure how you're planning on using isDynamicRef, but sure 👍

[xedin]

We have a representation for this already - SelectedOverload - it has all of the types plus OverloadChoice which would give you base type and kind, why not use that directly?

[ahoppen]

The computation of SelectedOverloadInfo is using SelectedOverload under the hood but we need to do some more adjustments of key path overloads to get the behavior we need for code completion (see implementation of getSelectedOverloadInfo). In particular in the case of KeyPathDynamicMemberLookup we don’t return information for the subscript(keyPath:) declaration but for the key path member access itself. This requires forming a new constraint locator (https://github.com/apple/swift/pull/62359/files#diff-d57f6f2d466f1f207cdf2dbd0396a1dbb2caba7b6828ebdb9954948f0ac2b499R3876-R3891).

AFAICT we have the following options:

• Store the types that SelectedOverloadInfo contains in SelectedOverload. I don’t really like the idea because the information seems to be IDE-specific to me and not useful for general type checking.
• Add methods to SelectedOverload that compute the types stored in SelectedOverloadInfo. I don’t like this approach since the computation of CallBaseTy and FuncTy require the Solution in which the overload was picked as well as the ContraintLocator that referred to it.
• Name SelectedOverloadInfo something more IDE-specific
• Move getSelectedOverloadInfo into libIDE (where it essentially came from, previously it was a static function in ArgumentCompletion.cpp)

I think I like the last option best. WDYT @xedin?

[xedin]

I concur, let's move that functionally to libIDE and feed it information from SelectedOverload.

[ahoppen]

@swift-ci Please smoke test