We were still using ClangDirectLookup in just two places outside of
ClangImporter, both to enumerate members of C++ namespaces. (Doing so
was probably wrong after dbce64ec481493efdb38fc0fb1fbf51df981b7f5 since
ClangDirectLookup no longer handled inline namespaces.)
This patch introduces a new function, forEachCXXNamespaceMember, which
consolidates the logic from those call sites and migrates it to
ClangLookup.cpp.
Apart from those call sites, ClangDirectLookup is only used in one
other place: ClangRecordMemberLookup. This patch also gets rid of
ClangDirectLookup as a request, and converts it to a helper function
designated for record member lookups. It also cleans up much of the
implementation details, including an unintentional re-implementation of
getNonTransparentDeclContext(), thereby fixing two instances of #54905.
Note that commit causes a crash when looking up nested unscoped enum
members with ObjC interop (see ClangImporter/enum-anon{,-sized}.swift).
This is fixed in the subsequent commit, which deals specifically with
nested enum lookup.
rdar://170858363
Adds a new DynamicMemberLookupSubscriptRequest type for evaluating and
caching the validity of a `SubscriptDecl`'s usage to fulfill a
`@dynamicMemberLookup` requirement for a specific usage.
Adds support for `SubscriptDecl`s to fulfill `@dynamicMemberLookup`
requirements if they have additional arguments after `dynamicMember:` so
long as those arguments have default values, or are variadic.
This allows exposing values like `#function`, `#fileID`, `#line`, etc.
to dynamic member lookup.
We already reject attempts to reference this for `lazy` properties.
For `lazy` locals let's just not expose it to name lookup to begin
with. This ensures we don't attempt to prematurely kick the interface
type computation for the var, fixing a couple of crashers.
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)
We can avoid lookup entirely on invertible protocols because they never
can have any members. This saves us from having to update tests and
perhaps some extra work in code completion.
I had to disable typo correction in one test case to get it to pass without
diagnosing a cycle as a result of Sendable checking. But that's OK, because:
- Sendable checking is prone to request cycles and needs to be redesigned
- Typo correction is turned off in production
* Don't invalidate the lookup cache in 'getOrCreateSynthesizedFile()'
Adding a synthesized file itself doesn't introduce any decls. Instead,
we should invalidate the right after the actual declrations are added
in the file
* Remove 'SourceLookupCache::invalidate()' method. It was just used
right before the destruction. It was just not necessary
* Include auxiliary decls in 'SourceLookupCache::lookupVisibleDecls()'
Previously, global symbol completion didn't include decls synthesized
by peer macros or freestanding decl macros
* Include "auxiliary decls" in visible member lookup, and visible local
decl lookup
* Hide macro unique names
rdar://110535113
This source location will be used to determine whether to add a name lookup
option to exclude macro expansions when the name lookup request is constructed.
Currently, the source location argument is unused.
Global peer macro expansions are not injected into the AST. Instead, they
are visited as "auxiliary declarations" when needed, such as in the decl
checker and during SILGen. This is the same mechanism used for local property
wrappers and local lazy variables.
The result values of the expansion requests for attached macros tended
to be useless, because most of their operation is via side effects on
the nodes they are attached to. Replace the result values with an
array of expansion buffer IDs, so clients can see what effect the
macro expansion had.
Although the declaration of macros doesn't appear in Swift source code
that uses macros, they still operate as declarations within the
language. Rework `Macro` as `MacroDecl`, a generic value declaration,
which appropriate models its place in the language.
The vast majority of this change is in extending all of the various
switches on declaration kinds to account for macros.
`lookupVisibleMemberDecls` visits nominal type decls to find visible
members of the type. Remembering what decls are visited can be useful
information for the clients.
* Add a 'VisibleDeclConsumer' callback function that is called when
'lookupVisibleDecls' visits each nominal type decls
* Remember the decl names in 'CodeCompletionContext' for future use
Tweaked usable check:
* Local type/func decls are usable even before declaration
* Outer nominal Instance member are not usable
* Type context cannot close over values in outer type contexts
Added shadowing rule by the base name:
* Type members don't shadow each other as long as they are in the
same type context.
* Local values shadow everything in outer scope
* Except that 'func' decl doesn't shadow 'var' decl if they are in the
same scope.
rdar://86285396
The new type, called ExistentialType, is not yet used in type resolution.
Later, existential types written with `any` will resolve to this type, and
bare protocol names will resolve to this type depending on context.
Typo correction would call directly into the GenericSignatureBuilder
to get a list of all nested types of a type parameter.
Since the time that code was written, higher level APIs were added to
GenericSignature which originally wrapped the GenericSignatureBuilder.
These days when the rewrite system is enabled, the GenericSignature
operations also use the rewrite system, and the long-term goal is
to get rid of GenericSignatureBuilder altogether.
In the following test case, we are crashing while building the generic signature of `someGenericFunc`, potentially invoked on `model` in line 11.
```swift
struct MyBinding<BindingOuter> {
func someGenericFunc<BindingInner>(x: BindingInner) {}
}
struct MyTextField<TextFieldOuter> {
init<TextFieldInner>(text: MyBinding<TextFieldInner>) {}
}
struct EncodedView {
func foo(model: MyBinding<String>) {
let _ = MyTextField<String>(text: model)
}
}
```
Because we know that `model` has type `MyBinding<TextFieldInner>`, we substitute the `BindingOuter` generic parameter by `TextFieldInner`. Thus, `someGenericFunc` has the signature `<TextFieldInner /* substitutes BindingOuter */, BindingInner>`. `TextFieldInner` and `BindingOuter` both have `depth = 1`, `index = 0`. Thus the verification in `GenericSignatureBuilder` is failing.
After discussion with Slava, the root issue appears to be that we shouldn’t be calling `subst` on a `GenericFunctionType` at all. Instead we should be using `substGenericArgs` which doesn’t attempt to rebuild a generic signature, but instead builds a non-generic function type.
--------------------------------------------------------------------------------
We slightly regress in code completion results by showing two `collidingGeneric` twice in the following case.
```swift
protocol P1 {
func collidingGeneric<T>(x: T)
}
protocol P2 {
func collidingGeneric<T>(x: T)
}
class C : P1, P2 {
#^COMPLETE^#
}
```
Previously, we were representing the type of `collidingGeneric` by a generic function type with generic param `T` that doesn’t have any restrictions. Since we are now using `substGenericArgs` instead of `subst`, we receive a non-generic function type that represents `T` as an archetype. And since that archetype is different for the two function signatures, we show the result twice in code completion.
One could also argue that showing the result twice is intended (or at least acceptable) behaviour since, the two protocol may name their generic params differently. E.g. in
```swift
protocol P1 {
func collidingGeneric<S>(x: S)
}
protocol P2 {
func collidingGeneric<T>(x: T)
}
class C : P1, P2 {
#^COMPLETE^#
}
```
we might be expected to show the following two results
```
func collidingGeneric<S>(x: S)
func collidingGeneric<T>(x: T)
```
Resolves rdar://76711477 [SR-14495]
struct Point { var x, y: Int }
protocol P {}
extension P {
subscript<T>(dynamicMember key: KeyPath<Point, T>) -> T
}
@dynamicMemberLookup struct S: P {}
S().<HERE>
Previously, completion couldn't suggest 'x' and 'y'. Include
'NL_ProtocolMembers' when finding 'subscript(dynamicMember:)'.
rdar://problem/71008072
Strings are a single token, so the previous check would treat
completions inside string interpolations as being outside of the
initializer.
Grab the end of the token from the Lexer, but wrap in a context check to
avoid performing that for every declaration found in the lookup.
Resolves rdar://70833348
`::lookupVisibleDecls` had an inline consumer in order to remove
"unusable" results. Refactor this method, moving the consumer (now
`UsableFilteringDeclConsumer`) to allow its use when looking up top
level module declarations.
Also use the `AccessFilteringDeclConsumer` in preference to a condition
in `addVarDecl`.
Resolves rdar://56755598
John Hui
Slava Pestov
Itai Ferber
Hamish Knight
Anthony Latsis
Allan Shortlidge
Tim Kientzle
Kavon Farvardin
Alex Lorenz
Rintaro Ishizaki
Holly Borla
Doug Gregor
Josh Soref
Pavel Yaskevich
Alex Hoppen
Anthony Latsis
Ben Barham
Ellis Hoag