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
'lookupTypeMembers()' accepts 'BaseTy' to check found value decls are
applicable to the type. When looking into super classes, it used to use
the interface type of the super class which was not good.
Instead, use the original "base type" consistently.
rdar://problem/69308207
https://bugs.swift.org/browse/SR-13574
