```swift
protocol Proto {}
struct ConcreteProto {}
struct MyStruct<T> {}
extension MyStruct where T: Proto {
static var option: MyStruct<ConcreteProto> { get }
}
func foo<T: Proto>(arg: MyStruct<T>) {}
func test() {
foo(arg: .#^HERE^#)
}
```
In this case, the type of `MyStruct.option` is `MyStruct<ConcreteProto>`
whereas the context type is `MyStruct<T> where T: Proto`.
When checking the convertibility of them , we need to "open archetype types".
rdar://problem/24570603
rdar://problem/51723460
In parser, 'parseExprPostfixSuffix()' can parse postfix expression for
'super'. 'parseExprSuper()' doesn't need to parse them.
In code-completion, 'completeExprSuper()' and 'completeExprSuperDot()'
can be consolidated to 'completePostfixExpr()' and 'completeDotExpr()'.
```
@#^COMPLETE^#
public func something() {}
```
In this case, we can't say the user is adding attribute to the func or
starting a new declaration. So if there're one or more blank lines after the
completion, suggest context free attribute list.
rdar://problem/50441643
There's no attribute declared for PatternBindingDecl. There are for
VarDecl. Code completion should consider DeclKind::PatternBinding as
DeclKind::Var.
Clearing the cache and the end of the for loop invalidates the interator
and prevents iterating through the rest of the vector. This should be
cleared after we're done iterating.
When performing keypath dynamic member lookup, avoid substituting the
base type in override detection and completion, as the base type of the
lookup is not the base type of the member. For now, we just avoid the
substitution entirely to fix potential crashes; in a future commit we
will change to using the subscript return type and substituting with the
base type of the subscript instead of the base type of the lookup.
rdar://50449788
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.)
Once the '@escaping' bit is removed from TupleTypeElt, it no longer makes
sense to print argument lists as if they were TupleTypes or ParenTypes,
since function types are '@escaping' by default inside tuples but not
in argument lists.
Instead, print ArrayRef<AnyFunctionType::Param> directly. For now this
introduces some awkward usages of AnyFunctionType::decomposeInput();
these will go away once the AST is changed to represent the argument list
as a list of expressions and not a single tuple expression.
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
