Today ParenType is used:
1. As the type of ParenExpr
2. As the payload type of an unlabeled single
associated value enum case (and the type of
ParenPattern).
3. As the type for an `(X)` TypeRepr
For 1, this leads to some odd behavior, e.g the
type of `(5.0 * 5).squareRoot()` is `(Double)`. For
2, we should be checking the arity of the enum case
constructor parameters and the presence of
ParenPattern respectively. Eventually we ought to
consider replacing Paren/TuplePattern with a
PatternList node, similar to ArgumentList.
3 is one case where it could be argued that there's
some utility in preserving the sugar of the type
that the user wrote. However it's really not clear
to me that this is particularly desirable since a
bunch of diagnostic logic is already stripping
ParenTypes. In cases where we care about how the
type was written in source, we really ought to be
consulting the TypeRepr.
This was causing us to emit diagnostics talking about τ_m_n, which is
not helpful.
Now that generic function types print sanely, print them in a few
places where we were previously printing PolymorphicFunctionTypes.
* [FixCode] Add @escaping when overriding mismatch is because of it. rdar://27814862
With the change of default escaping behavior, users' existing code overriding
objc functions may need to add @escaping to make the overriding match as before. This
patch checks if an overriding mismatch is due to the lacking of @escaping and add
it as a fixit.
* [test] Update existing test. NFC
Otherwise, we'll treat lookups on generic parameters as ambiguous,
since we don't have a concrete nominal type to use (coincidentally)
as the "base" of each lookup result.
It's possible we can get rid of this condition altogether, but I don't
want to rock the boat for unqualified lookup right now.
rdar://problem/23087787
