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.
To represent the abstracted interface of an opaque type, we need a generic signature that refines
the outer context generic signature with an additional generic parameter representing the underlying
type and its exposed constraints. Opaque types also need to be keyed by their originating decl, so
that we can treat values of the same opaque type as the same. When we check a FuncDecl with an
opaque type specified as its return type, create an OpaqueTypeDecl and associate it with the
originating decl. (A representation for *types* derived from the opaque decl will come next.)
Looks into the root type of the keypath to find additional members. This
does not currently map the type of the completion to the subscript's
return type.
rdar://49029126
This is an attribute that gets put on an import in library FooKit to
keep it from being a requirement to import FooKit. It's not checked at
all, meaning that in this form it is up to the author of FooKit to
make sure nothing in its API or ABI depends on the implementation-only
dependency. There's also no debugging support here (debugging FooKit
/should/ import the implementation-only dependency if it's present).
The goal is to get to a point where it /can/ be checked, i.e. FooKit
developers are prevented from writing code that would rely on FooKit's
implementation-only dependency being present when compiling clients of
FooKit. But right now it's not.
rdar://problem/48985979
...in preparation for me adding a third kind of import, making the
existing "All" kind a problem. NFC, except that I did rewrite the
ClangModuleUnit implementation of getImportedModules to be simpler!
When a type conditionally conforms to a protocol, it used to provide
symbols from extension to that protocol.
e.g.:
protocol P {}
extension P {
func foo() {}
}
struct S<T> {}
extension S: P where T == Int {}
func test(val: S<String>) {
val.#^COMPLETE^#
}
This should not provide `foo()` method.
rdar://problem/36594731
The logic here had diverged from UnqualifiedLookup. One day we'll merge
the two, for now clean it up a bit to match.
Note that all generic parameters now have 'Reason' reported as 'Local'.
I don't believe this really matters.
Fixes <rdar://problem/20530021>.
Consider this setup:
protocol Proto {
func foo() {}
}
class Base : Proto {
func foo() {}
}
class Derived : Base {
...
}
When completing members of a Derived instance, we find both the protocol's
foo() and the base class's foo(). These have the following types:
- Proto.foo: <Self : Proto> (Self) -> () -> ()
- Base.foo: (Base) -> () -> ()
If we simply substitute the base type (Derived) into the type of the protocol
member, we get (Derived) -> () -> (), which is different than the type of
Base.foo, so we get both declarations in the completion list.
Instead, use the 'Self' type for the specific class of the conformance,
which in this case is 'Base' even if we're looking at members of 'Derived'.
Fixes <rdar://problem/21161476>, <https://bugs.swift.org/browse/SR-1181>.
Semantically, these are not superclass/refined-protocol members.
If I have a generic parameter <T : P & Q>, then when looking at
a value of type T, members of P and Q are at the same "level" as
if I had a value of type (P & Q).
AST/LookupVisibleDecls.cpp has a dependency on swiftSema by having doGlobalExtensionLookup call into swift::isExtensionApplied,
and doGlobalExtensionLookup is ultimately used by the other global functions in that file.
Break the cycle by moving the file into the swiftSema library.
