This is a travesty that makes it hard to reason about tuple vs. scalar
types. It's only use in our own code involved dealing with the
difference in element types between Set and Dictionary in
gyb-generated code. Ewww. Fixes rdar://problem/17963034.
Swift SVN r30074
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
value member constraints do.
This fixes:
<rdar://problem/21662365> QoI: diagnostic for for-each over an optional sequence isn't great
before we'd produce:
t.swift:3:10: error: '[Int]?' does not have a member named 'Generator'
for x in array {
^
now we produce:
t.swift:3:10: error: value of optional type '[Int]?' not unwrapped; did you mean to use '!' or '?'?
for x in array {
^
Swift SVN r29902
It looks like we were checking in the wrong place, as a result we didn't
catch stuff like
class G<T : AnyObject> {}
_ = G<P>()
This would crash later in IRGen.
Make the conformsToProtocol() check do the right thing, and remove some
other miscellaneous diagnostics in the process. Also, make the
"type 'T' does not conform to protocol 'P'" diagnostic a bit more
detailed.
Unfortunately in a few instances we lose a more descriptive diagnostic to
a general 'cannot invoke 'foo' with argument list of type 'T'' error. The
argument matching diagnostics need to be addressed anyway though.
Fixes <rdar://problem/20311619>.
Swift SVN r29737
We don't know what's inside the existential type container, so we cannot
refer to uncurried instance members of the type without running into
theoretical difficulties.
Swift SVN r29378
For a concrete type A and protocol type P, A <c P now implies
A.Type <c P.Type, not just A.Type < P.Type. This in turn means
that A.Type.Type <c P.Type.Type. To make the coercion work,
recursively peel off metatype layers when collecting conformances
and in a similar situation in IRGen.
Swift SVN r29377
We were using getRValueType() and getRValueObjectType() when
setting up the constraint, but getRValueType() when simplifying
it. This led to a crash if the type was a single-argument tuple
with a named argument.
Swift SVN r29376
X.Protocol is an instance of Y.Type only if X conforms to Y. Since X
is a protocol, this is only true if X contains Y and Y is
self-conforming.
Note that this updates some tests that actually contained invalid code.
Fixes <rdar://problem/20915927>.
Swift SVN r29349
If 'x.init' appears as a member reference other than 'self.init' or 'super.init' within an initializer, treat it as a regular static member lookup for 'init' members. This allows a more explicit syntax for dynamic initializations; 'self.someMetatype()' looks too much like it's invoking a method. It also allows for partial applications of initializers using 'someMetatype.init' (though this needs some SILGen fixes, coming up next). While we're in the neighborhood, do some other correctness and QoI fixes:
- Only lookup initializers as members of metatypes, not instances, and add a fixit (instead of crashing) to insert '.dynamicType' if the initializer is found on an instance.
- Make it so that constructing a class-constrained archetype type correctly requires a 'required' or protocol initializer.
- Warn on unused initializer results. This seems to me like just the right thing to do, but is also a small guard against the fact that 'self.init' is now valid in a static method, but produces a newly-constructed value instead of delegating initialization (and evaluating to void).
Swift SVN r29344
If P is a protocol, calling static methods or constructors
via values of type P.Protocol makes no sense, so let's prohibit
this.
Fixes <rdar://problem/21176676>.
Swift SVN r29338
Rename existentialConformsToSelf() to existentialTypeSupported(). This
predicate is the "protocol has no Self or associated type requirements"
check, which is a looser condition than self-conformance. This was being
tested to see if the user could refer to the protocol via an existential
type.
The new existentialConformsToSelf() now checks for protocol being @objc,
and for the absence of static methods. This is used as part of the
argument type matching logic in matchType() to determine if the
existential can be bound to a generic type parameter.
The latter condition is stricter, for two reasons:
1) We allow binding existentials to multiple type parameters all sharing
the same generic type parameter T, so we don't want the user to be
able to see any static methods on T.
2) There is an IRGen limitation whereby only existentials without witness
tables can be passed in this manner.
Using the above, the representsNonTrivialGenericParameter() function
has been renamed to canBindGenericParamToExistential(). It now allows
an existential type to be bound to a generic type parameter only under
the following circumstances:
A) If the generic type parameter has no conformances, the match is allowed.
B) If the generic type parameter has at least one conformance, then all
of the conformances on the generic type parameter must be
existentialConformsToSelf() (condition 1 above), and all conformances
on the existential must be @objc (condition 2 above).
Fixes <rdar://problem/18378390> and <rdar://problem/18683843>, and lays
the groundwork for fixing a few other related issues.
Swift SVN r29337
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
This just deletes some code out of matchCallArguments to make sure that CSApply
and CSSimplify do the same argument matching. This code presumably
dated to a period of time when the stuff after it was just for error recovery,
but now we do argument reordering matching stuff after this point.
Swift SVN r28670
Modules occupy a weird space in the AST now: they can be treated like
types (Swift.Int), which is captured by ModuleType. They can be
treated like values for disambiguation (Swift.print), which is
captured by ModuleExpr. And we jump through hoops in various places to
store "either a module or a decl".
Start cleaning this up by transforming Module into ModuleDecl, a
TypeDecl that's implicitly created to describe a module. Subsequent
changes will start folding away the special cases (ModuleExpr ->
DeclRefExpr, name lookup results stop having a separate Module case,
etc.).
Note that the Module -> ModuleDecl typedef is there to limit the
changes needed. Much of this patch is actually dealing with the fact
that Module used to have Ctx and Name public members that now need to
be accessed via getASTContext() and getName(), respectively.
Swift SVN r28284
checking checked cast via bridging. It prevented bridging upcasts using
'as!' from typechecking; we should emit an 'as!'->'as' warning instead.
Also, use ExplicitConversion constraint instead of Conversion when
determining whether a checked cast can be carried out unconditionally.
This matches the constraint used after applying the 'as!'->'as' fixit.
(Also, fix the error that was responsible for breaking
the expr/cast/bridged.swift test.)
<rdar://problem/19813772>
Swift SVN r28034
checking checked cast via bridging. It prevented bridging upcasts using
'as!' from typechecking; we should emit an 'as!'->'as' warning instead.
Also, use ExplicitConversion constraint instead of Conversion when
determining whether a checked cast can be carried out unconditionally.
This matches the constraint used after applying the 'as!'->'as' fixit.
<rdar://problem/19813772>
Swift SVN r28028
ConstraintSystem::dump to ConstraintSystem::print for
consistency with other parts of the compiler. Enhance
CS::print to print the ID # of a Type Variable, so you
don't have to count them to realize that you're looking
at typevar #13
Swift SVN r27874
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
This reverts commit r27576.
(In some cases of catastrophic error recovery, ctor types may still be null during constraint solving, so it was wrong of me to assume otherwise.)
Swift SVN r27599
This reverts commit r27568 to unblock the buildbot. It regressed three
compiler crashers:
Swift :: compiler_crashers_fixed/0367-llvm-errs.swift
Swift :: compiler_crashers_fixed/1769-getselftypeforcontainer.swift
Swift :: compiler_crashers_fixed/1916-swift-nominaltypedecl-getdeclaredtypeincontext.swift
Swift SVN r27576
- When inferring 'throws' for a closure function type, look inside of catchless do blocks for 'try' expressions.
- When simplifying overload constriants for applications of throwing initializers, the bound member type of the initializer should also be marked as throwing.
(Not doing so would cause us to incorrectly reject the overload.)
Swift SVN r27568
Fix crashes when type-checking ErrorType dynamic casts when NSError isn't available. Split the ErrorType execution tests into separate units for bridging and non-bridging, so that we get better coverage of this situation in both ObjC and non-ObjC builds. Fixes rdar://problem/20585210.
Swift SVN r27556
The post-type-checking error that was here is arguably better QoI, but it is causing ambiguities that break the non-ObjC-compatible build in the stdlib. We shouldn't even attempt these conversions if there's no runtime support to back them up.
Swift SVN r27407
A non-throwing function can be a trivial subtype of a throwing
function. Encode this rule more directly, introduce some additional
tests to ensure that we get the behavior right where we need exact
matches, and add a failure kind with custom diagnostic for cases where
function types mismatch due to 'throws'.
Swift SVN r27255
Previously some parts of the compiler referred to them as "fields",
and most referred to them as "elements". Use the more generic 'elements'
nomenclature because that's what we refer to other things in the compiler
(e.g. the elements of a bracestmt).
At the same time, make the API better by providing "getElement" consistently
and using it, instead of getElements()[i].
NFC.
Swift SVN r26894
This pushes tuple pattern labels forward:
- Actually record them in TuplePatternElt.
- Remove the tuple shuffle ban that prevents some cases
(e.g. the one in the radar) of a tuple with labels being shuffled
onto a tuple without labels.
- Remove dead code enabled by removing the restriction.
Swift SVN r26852
