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.
