Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
Cursor info only cares about the `doneParsing` callback and not about all the `complete` functions that are now defined in `CodeCompletionCallbacks`. To make the design clearer, split `IDEInspectionCallbacks`.
rdar://105120332
This will be necessary to make cursor info completion like to inspect the just parsed source file because the callback from parsing the code completion token won’t be called.
The code completion might occur inside an attriubte that isn’t part of the AST because it’s missing a `VarDecl` that it could be attached to. In these cases, record the `CustomAttr` and type check it standalone, pretending it was part of a `DeclContext`.
This also fixes a few issues where code completion previously wouldn’t find the attribute constructor call and thus wasn’t providing code completion inside the property wrapper.
rdar://92842803
Previously we were defaulting to the method's
interface type, which could lead to calling `subst`
with a GenericFunctionType. Instead, pass the
result type only, as that's all we want anyway.
rdar://77259607
Checking for staticness is not enough because top-level decls count as
non-static yet do not have a sufficient curry level to satisfy this
check. Make sure we're looking for decls that reside inside of types.
rdar://75299825, SR-14327
LLVM, as of 77e0e9e17daf0865620abcd41f692ab0642367c4, now builds with
-Wsuggest-override. Let's clean up the swift sources rather than disable
the warning locally.
Protocol extension only members are not customization point. Code
completion should not suggest them in override/conformance completion.
rdar://problem/53591636
Note that in all cases it was either nullptr or ctx.getLazyResolver().
While passing in nullptr might appear at first glance to mean something
("don't type check anything"), in practice we would check for a nullptr
value and pull out ctx.getLazyResolver() instead. Furthermore, with
the lazy resolver going away (at least for resolveDeclSignature() calls),
it won't make sense to do that anymore anyway.
This commit adds a new type DynamicLookupInfo that provides information
about how a dynamic member lookup found a particular Decl. This is
needed to correctly handle KeyPath dynamic member lookups, but for now
just plumb it through everywhere.
The client usually cares about a subset of all expressions. A way to differentiate
them is by the protocols these expressions' types conform to. This patch allows
the request to add a list of protocol USRs so that the response only includes those
interested expressions that conform to any of the input protocols.
We also add a field to the response for each expression type to indicate the
conforming protocols names that were originally in the input list.
When an empty list of protocol USRs are given, we report all expressions' types
in the file like the old behavior.
rdar://35199889
`source.request.conformingmethods` is a new SourceKit request which
receives a source position and a list of protocol namses, returns a list
of methods whose return type conforms to the requested protocols.
rdar://problem/44699573
