As part of this, use a different enum for parsed generic requirements.
NFC except that I noticed that ASTWalker wasn't visiting the second
type in a conformance constraint; fixing this seems to have no effect
beyond producing better IDE annotations.
A decl’s full GenericSignature is set during validateGenericTypeSignature().
Then during ConstraintSystem::openTypes(), in ReplaceDependentTypes, the GenericArgs list is built from the generic signature (via getGenericParamTypes()) and passed into a new BoundGenericType.
In BoundGenericType::getSubstitutions(), the GenericArgs are assumed to match getGenericParamsOfContext()->getParams().
However, in reality, the GenericArgs include all levels of generic args, whereas getGenericParamsOfContext() are the params of the innermost context only, so the params array is accessed past its end.
This commit changes NominalTypeDecl::getGenericParamTypes() to return the innermost params, in order to match the output of BoundGenericType::getGenericArgs(). For clarity and to hopefully prevent future confusion, we also rename getGenericParamTypes() to getInnermostGenericParamTypes().
Eliminate the last client of DependentTypeOpener,
RequirementTypeOpener, which tracked the opened Self type when doing
witness/requirement matching and substituted in the known type
witnesses for that protocol. It had a bunch of dead logic hanging
around from the days where we used the constraint system to deduce
type witnesses. Now, a simple substitution suffices.
With its last client gone, remove DependentTypeOpener as well.
The ArchetypeOpener was used only to replace dependent types with
archetypes (or concrete types) within the opening context. We can do
the same simply by letting the constraint system create type variables
and then binding those type variables to the appropriate
archetypes/concrete types in that context.
Eliminate the two DependentTypeOpener entry points that were only used
by the ArchetypeOpener.
Parameters (to methods, initializers, accessors, subscripts, etc) have always been represented
as Pattern's (of a particular sort), stemming from an early design direction that was abandoned.
Being built on top of patterns leads to patterns being overly complicated (e.g. tuple patterns
have to have varargs and default parameters) and make working on parameter lists complicated
and error prone. This might have been ok in 2015, but there is no way we can live like this in
2016.
Instead of using Patterns, carve out a new ParameterList and Parameter type to represent all the
parameter specific stuff. This simplifies many things and allows a lot of simplifications.
Unfortunately, I wasn't able to do this very incrementally, so this is a huge patch. The good
news is that it erases a ton of code, and the technical debt that went with it. Ignoring test
suite changes, we have:
77 files changed, 2359 insertions(+), 3221 deletions(-)
This patch also makes a bunch of wierd things dead, but I'll sweep those out in follow-on
patches.
Fixes <rdar://problem/22846558> No code completions in Foo( when Foo has error type
Fixes <rdar://problem/24026538> Slight regression in generated header, which I filed to go with 3a23d75.
Fixes an overloading bug involving default arguments and curried functions (see the diff to
Constraints/diagnostics.swift, which we now correctly accept).
Fixes cases where problems with parameters would get emitted multiple times, e.g. in the
test/Parse/subscripting.swift testcase.
The source range for ParamDecl now includes its type, which permutes some of the IDE / SourceModel tests
(for the better, I think).
Eliminates the bogus "type annotation missing in pattern" error message when a type isn't
specified for a parameter (see test/decl/func/functions.swift).
This now consistently parenthesizes argument lists in function types, which leads to many diffs in the
SILGen tests among others.
This does break the "sibling indentation" test in SourceKit/CodeFormat/indent-sibling.swift, and
I haven't been able to figure it out. Given that this is experimental functionality anyway,
I'm just XFAILing the test for now. i'll look at it separately from this mongo diff.
Previously, methods on DeclContext for getting generic parameters
and signatures did not walk up from type contexts to function
contexts, or function contexts to function contexts.
Presumably this is because SIL doesn't completely support nested
generics yet, instead only handling these two special cases:
- non-generic local function inside generic function
- generic method inside generic type
For local functions nested inside generic functions, SIL expects
the closure to not have an interface type or generic signature,
even if the contextual type signature contains archetypes.
This should probably be revisited some day.
Recall that these cases are explicitly rejected by Sema diagnostics
because they lack SIL support:
- generic function inside generic function
- generic type inside generic function
After the previous patches in this series, it becomes possible to
construct types that are the same as before for the supported uses of
nested generics, while introducing a more self-consistent conceptual
model for the unsupported cases.
Some new tests show we generate diagnotics in various cases that
used to crash.
The conceptual model might still not be completely right, and of
course SIL, IRGen and runtime support is still missing.
Now that generic signatures of types include generic parameters
introduced by outer generic functions, we need to know to skip
them when forming bound generic types or substitutions.
Add a function that computes the depth of the innermost generic
context that is not a generic type context.
This avoids us using reserved identifiers as the enum case names of all
our underscored protocols like _ObjectiveCBridgeable. I used the
convention PROTOCOL_WITH_NAME to mirror how the known identifiers work.
Swift SVN r32924
Introduce a new constraint kind, BindParam, which relates the type of a
function parameter to the type of a reference to it from within the
function body. If the param type is an inout type, the ref type is an
lvalue type with the same underlying object type; otherwise the two
types must be the same. This prevents DeclRefExprs from being inferred
to have inout type in some cases.
<rdar://problem/15998821> Fail to infer types for closure that takes an inout argument
Swift SVN r32183
Introduce a new "OpenedGeneric" locator for when openGeneric opens a generic
decl into a plethora of constraints, and use this in CSDiags to distinguish
whether a constraint refers to an Expr as a whole or an "aspect" of the constraint.
Use that information in FailureDiagnosis::diagnoseGeneralConversionFailure
to know whether (as a fallback) we can correctly re-typecheck an entire expr
to obtain a missing type. If we are talking about an aspect of the expr, then
this clearly won't work.
The upshot of this is that where we previously compiled the testcase in 22519983
to:
y.swift:31:9: error: type '(inout _) -> Bool' does not conform to protocol 'RawRepresentable'
let a = safeAssign
^
we now produce the somewhat more useful:
y.swift:31:9: error: argument for generic parameter 'T' could not be inferred
let a = safeAssign
^
y.swift:27:6: note: in call to function 'safeAssign'
func safeAssign<T: RawRepresentable>(inout lhs: T) -> Bool {
^
Swift SVN r31620
bases. Consider this example (reduced from NameBinding/name_lookup.swift):
class ThisBase1 {
func baseFunc0() {}
}
class ThisDerived1 : ThisBase1 {
class func staticTestSelf1(a : ThisBase1) {
let x = self.baseFunc0
x(a)()
}
}
The type checker was incorrectly blasting over the self type of the 'self.baseFunc0'
reference, giving 'x' a type of "ThisDerived -> () -> ()" instead of the correct
type of "ThisBase -> () -> ()" and rejecting the testcase.
I'm not confident that this is the right fix, review greatly appreciated!
Swift SVN r30641
The isDependentType() query is woefully misunderstood. Some places
seem to want it to mean "a generic type parameter of dependent member
type", which corresponds to what is effectively a type parameter in
the language, while others want it to mean "contains a type parameter
anywhere in the type". Tease out these two meanings in
isTypeParameter() and hasTypeParameter(), respectively, and sort out
the callers.
Swift SVN r29945
... I have no idea why we were foolishly mapping such things to their
parent type, which made no sense whatsoever. Fixes
rdar://problem/21621421.
Swift SVN r29882
In r26737, Sema was changed to not wrap Self occurring in a protocol
extension in a DynamicSelf. The commit message was rather terse but
I believe this is because the metadata for Self is bound to the static
base type, not the runtime base type.
However, we still need to substitute Self in the return type for the
static base type in the case where the base is an existential,
otherwise we get an open existential type leaking out.
Also remove the default argument for replaceCovariantResultType(),
every call site passed in a value and it seems bad to omit it on
accident.
Fixes <rdar://problem/21433694>.
Swift SVN r29802
We were dropping *all* constraints on the Self type when forming
constraints from a protocol member, which included the extra
constraints provided by constrained extensions. Only drop the actual
protocol in which the member occurs (or the protocol extended by the
containing extension).
Fixes rdar://problem/21401180 and the 8 dupes I've found so far.
Swift SVN r29708
We diagnose usage of invalid existential types but we might still
try to compute substitutions. Just whip up an ErrorType instead.
Fixes <rdar://problem/16803384>.
Swift SVN r29567
lvalues when compiling list of partial-match overloads in diagnosis.
(This is a reapplication of commits r29462 and r29469.)
Also, fix the following tests:
stdlib/FixedPointDiagnostics.swift.gyb
stdlib/NumericDiagnostics.swift.gyb
<rdar://problem/17875634> can't append to array of tuples
Swift SVN r29493
This reverts commit r29462 because it looks like it breaks the following
tests:
Swift :: stdlib/FixedPointDiagnostics.swift.gyb
Swift :: stdlib/NumericDiagnostics.swift.gyb
Swift SVN r29484
Always rewrite the Self type to the base type. Previously we only
did it if the method had a dynamic self return. This caused some
confusing behavior in this case:
class C {
func m1() {}
func m2() -> Self {}
}
class D : C {}
The types of D.m1 and D.m2 are:
- D.m1: C -> () -> ()
- D.m2: D -> () -> D
For protocols, this also meant that the type of an instance method
reference P.f had an open existential that could "leak out" of
the OpenExistentialExpr. Now, P.f will have type P -> ... -> ...,
however using such a reference still crashes, just in SILGen
instead of Sema, because we don't generate the right thunks yet.
Progress on <rdar://problem/21289579>.
Swift SVN r29447
Special-casing these as MemberRefExprs created an asymmetry
where unbound archetype instance methods (<T : P> T.f) could
not be represented. Treating class and protocol methods
uniformly also eliminates a handful of special cases around
MemberRefExpr.
SILGen's RValue and call emission peepholes now have to know
about DeclRefExprs that point to protocol methods.
Finally, generalize the diagnostic for partially applied
mutating methods to any partially applied function with an
inout parameter, since this is not supported.
Fixes <rdar://problem/20564672>.
Swift SVN r29298
variable has the must-be-materializable bit set if the old one does.
When assigning a fixed type to a type variable that must be
materializable, transfer the bit to any type variables within the fixed
type, as appropriate.
Add Options field to SavedTypeVariableBinding to save/restore type
variable options during solution.
<rdar://problem/21026806> Propagate MustBeMaterializable bit among type variables appropriately
Swift SVN r28883
Add a new option, TVO_MustBeMaterializable, to
TypeVariableType::Implementation, and set it for type variables
resulting from opening a generic type. This solution isn't complete (we
don't yet copy the non-materializable bit on unification of type
variables, and it's possible to bind a must-be-materializable type
variable to a type with type variables that later get bound to
non-materializable types) but it addresses all reported crashes for this
issue.
<rdar://problem/20807269> Crash in non-materializable type
Swift SVN r28792
Fix a nullptr dereference when looking for a base expression
in a member access. Remove use of Optional<T*>, it wasn't providing
any value versus nullptr checking.
Swift SVN r28648
When in an initializer, we allow setting into immutable properties
provided that the type of base in `base.member` matches that of that
initializer's containing type. This was an approximation for allowing
full access into `self` during initialization but this doesn't work when
passing in a different struct of the same type because that struct
should be still be immutable.
Check whether the base of the member access is the implicit self
parameter of the initializer before allowing mutation.
rdar://problem/19814302
Swift SVN r28634
When performing unqualified lookup within a type context (or method
thereof) that is a protocol or a protocol extension, use the Self
archetype of the protocol or extension so we look in types implied by
the requirements as well. Part of rdar://problem/20509152, fixing the
example provided in rdar://problem/20694545.
Swift SVN r28363
In addition to being better for performance in these cases, this disables the "self."
requirement in these blocks. {}() constructs are often used to work around statements
that are not exprs in Swift, so they are reasonably important.
Fixing this takes a couple of pieces working together:
- Add a new 'extraFunctionAttrs' map to the ConstraintSystem for solution
invariant function attributes that are inferred (like @noescape).
- Teach constraint simplification of function applications to propagate
@noescape between unified function types.
- Teach CSGen of ApplyExprs to mark the callee functiontype as noescape
when it is obviously a ClosureExpr.
This is a very limited fix in some ways: you could argue that ApplyExpr should
*always* mark its callee as noescape. However, doing so would just introduce a
ton of function conversions to remove it again, so we don't do that.
Swift SVN r27723
Add syntax "[#Color(...)#]" for object literals, to be used by
Playgrounds for inline color wells etc. The arguments are forwarded to
the relevant constructor (although we will probably change this soon,
since (colorLiteralRed:... blue:... green:... alpha) is kind of
verbose). Add _ColorLiteralConvertible and _ImageLiteralConvertible
protocols, and link them to the new expressions in the type checker.
CSApply replaces the object literal expressions with a call to the
appropriate protocol witness.
Swift SVN r27479
