The change to resolve ObjC #keyPath expression components caused some source
breakage as they are now being checked for availability issues. This change
updates availability checking to demote error diagnostics to warnings
within #keyPath expressions. There were cases in the source compat suite where
unavailble properites were used in #keyPath expressions, but they caused no
issues at runtime because the properties' ObjC runtime name was still correct
(e.g. the same as its renamed-to property in Swift).
Unlike \keypath expressions, only the property components of #keypath
expressions were being resolved, so index wouldn't pick up references for their
qualifying types.
Also fixes a code completion bug where it was reporting members from the Swift
rather than ObjC side of bridged types.
Resolves rdar://problem/61573935
Unlike \keypath expressions, only the property components of #keypath
expressions were being resolved, so index wouldn't pick up references for their
qualifying types.
Also fixes a code completion bug where it was reporting members from the Swift
rather than ObjC side of bridged types.
Resolves rdar://problem/61573935
Since `binding` has all of the required information now it's possible
to use its `locator` as a source of type variable assignment
(`Bind` constraint) in `TypeVariableBinding::attempt` which helps
to improve diagnostics.
...and collapse StaticVar/ClassVar and StaticLet/ClassLet into
StaticProperty/ClassProperty.
"var" and "let" aren't great nouns to use in diagnostics to begin with,
especially alongside semantic terms like "instance method". Focus on
the type vs. non-type aspect instead with "property", which better
matches how people talk about member vars (and lets) anyway.
And add a test that exercises this exit path (although it won't crash
a compiler without my fixes because we do end up with ErrorType in
that case, not a nullptr).