which allows solving of a constraint system to succeed without emitting
errors in the face of ambiguous solutions. This is important for CSDiag
because it is in the business of trying to solve subexpressions of a global
expression - and it wants to know the difference between a subexpression
that is inherently impossible to solve, vs one that is simply ambiguous
because its context has been removed.
Use this in CSDiag's typeCheckChildIndependently() to provide it an
extra flag that enables this behavior. This is currently unused, so NFC
with this patch.
Swift SVN r30402
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
To use members of protocol extensions on existential types, we
introduce an OpenExistentialExpr expression to open up the existential
type (into a local archetype) and perform the operations on that local
archetype.
Unlike with uses of initializers or dynamic-Self-producing
methods of protocols, which produce similar ASTs, we have the type
checker perform the "open" operation and then track it through
constraint application. This scheme is better (because it's more
direct), but it's still using a simplistic approach to deciding where
the actual OpenExistentialExpr goes that needs improvement.
Swift SVN r26964
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
Previously, we were reconstructing this mapping from the "full" opened
type produced by declaration references. However, when dealing with
same-type constraints between associated types and type parameters, we
could end up with an incomplete mapping, which let archetypes slip
through. Most of the churn here is sorting out the locators we need to
use to find the opened-type information. Fixes rdar://problem/18208283
and at least 3 dupes of it that I've found so far.
Swift SVN r25375
Require 'as' when converting from Objective-C type to native type (but
continue to allow implicit conversion from native to Objective-C). This
conversion constraint is called ExplicitConversion; all implicit
conversions are covered by the existing Conversion constraint. Update
standard library and tests to match.
Swift SVN r24496
Specifically, it's not when
- the conformance is being used within a function body (test included)
- the conformance is being used for or within a private type (test included)
- the conformance is being used to generate a diagnostic string
We're still a bit imprecise in some places (checking ObjC bridging), but
in general this means less of an issue for checking literals.
Swift SVN r23700
Trying a collection literal early often means that we can determine
the element type from context, which saves us the work of trying to
guess at the element type firsthand.
Doing this seems to help some cases significantly:
- test/stdlib/ArrayNew.swift got about 20% faster in a release build
- I had to drop the threshold for the "expression too complex" test
case by 20x to still trigger the issue.
Swift SVN r22097
t2.swift:3:1: error: argument for generic parameter 'U' could not be
inferred
f(i)
^
t2.swift:2:6: note: in call to function 'f'
func f<T, U>(t: T) -> U? { return nil }
^
Our lack of decent locator information means that we don't get notes
in all of the cases we want them. I'll look at that separately.
Swift SVN r21921
Locators that refer to opened type parameters now carry information
about the source location where we needed to open the type, so that
(for example) we can trace an opened type parameter back to the
location it was opened. As part of this, eliminate the "rootExpr"
fallback, because we're threading constraint locators everywhere.
This is infrastructural, and should be NFC.
Swift SVN r21919
When we have a literal constraint on an optional type, and the
optional does not itself conform to the literal protocol, look through
the optional to determine whether its underlying type conforms to the
protocol. This essentially helps filter out dumb solutions that try
optional types where we should just be relying on the
value-to-optional conversion.
Should be NFC, since we would find the same solutions anyway.
Swift SVN r21918
When computing the set of potential bindings for a type variable with
a literal constraint, we suggest the default literal type as a
fallback. Suppress this suggestion in the cases where another
constraint provides a type that already has some kind of contextual
type information (that does conform to the protocol), making the
default literal type more of a fallback. When type-checking the given
declaration:
var dict: NSDictionary = [
"status": 200,
"people": [ [ "id": 255,
"name": [ "first": "John", "last": "Appleseed" ] ] ] ]
it reduces the number of solution states explored by 2/3, the number
of attempted type variable bindings by 3/4, and the number of
disjunctions explored by 1/3. This optimization is useful in general,
and lets type annotations guide the type checker to a much greater
extent. It also helps with rdar://problem/18269449.
Swift SVN r21878
This is another instance where we choose a favored constraint that
only type checks because we're bridging through NSNumber, causing
awful problems. Fixes rdar://problem/17962491.
Swift SVN r21445
The determination of “favored” constraints for binary expressions was comparing the second argument to the first parameter to decide if the constraint is favored. Coupled with implicit bridging conversions through NSNumber, this meant that “1.0/10” would become Int when Foundation was imported, and hilarity ensued.
Fix the heuristic for favored constraints, tidy up this code a bit, and add ==(NSString, NSString) to cope with the ambiguity this creates.
Swift SVN r21154
While we work out the remaining performance improvements in the type checker, we can improve the user experience for some "runaway solver" bugs by setting a limit on the amount of temporary memory allocated for type variables when solving over a single expression.
Exponential behavior usually manifests itself while recursively attempting bindings over opened type variables in an expression. Each one of these bindings may result in one or more fresh type variables being created. On average, memory consumption by type variables is fairly light, but in some exponential cases it can quickly grow to many hundreds of megabytes or even gigabytes. (This memory is managed by a distinct arena in the AST context, so it's easy to track.) This problem is the source of many of the "freezing" compiler and SourceKit bugs we've been seeing.
These changes set a limit on the amount of memory that can be allocated for type variables while solving for a single expression. If the memory threshold is exceeded, we can surface a type error and suggest that the user decompose the expression into distinct, less-complex sub-expressions.
I've set the current threshold to 15MB which, experimentally, avoids false positives but doesn't let things carry on so long that the user feels compelled to kill the process before they can see an error message. (As a point of comparison, the largest allocation of type variable data while solving for a single expression in the standard library is 592,472 bytes.) I've also added a new hidden front-end flag, "solver-memory-threshold", that will allow users to set their own limit, in bytes.
Swift SVN r20986
Modify TypeBase::getRValueType to structurally convert lvalues embedded in tuple and paren types. Inside the constraint solver, coerce types to rvalues based on the structural 'isLValueType' test rather than shallow 'is<LValueType>' checking. Fixes <rdar://problem/17507421>, but exposes an issue with call argument matching and lvalues <rdar://problem/17786730>.
Swift SVN r20442
Create a new "OptionalObject" constraint kind in the solver that relates an optional type to its payload type, preserving lvalue-ness, and use it to model ForceValueExpr under the optional-lvalues regime.
Swift SVN r20140
expression applications
(rdar://problem/15933674, rdar://problem/17365394 and many, many dupes.)
When solving for the type of a binOp expression, factor the operand expression
types into account when collating overloads for the operator being applied.
This allows the type checker to now infer types for some binary operations with
hundreds of nested components, whereas previously we could only handle a handful.
(E.g., "1+2+3+4+5+6" previously sent the compiler into a tailspin.)
Specifically, if one of the operands is a literal, favor operator overloads
whose operand, result or contextual types are the default type of the literal
convertible conformance of the the argument literal type.
By doing so we can prevent exponential behavior in the solver and massively
reduce the complexity of many commonly found constraint systems. At the same
time, we'll still defer to "better" overloads if the default one cannot be
applied. (When adding an Int8 to an Int, for example.)
This obviously doesn't solve all of our performance problems (there are more
changes coming), but there are couple of nice side-effects:
- By tracking literal/convertible protocol conformance info within type
variables, I can potentially eliminate many instances of "$T0" and the
like from our diagnostics.
- Favored constraints are placed at the front of the overload resolution
disjunction, so if a system fails to produce a solution they'll be the
first to be mined for a cause. This helps preserve user intent, and leads
to better diagnostics being produced in some cases.
Swift SVN r19848
When we see a '.member' expression in optional context, look for the member in the optional's object type if it isn't found in Optional itself. <rdar://problem/16125392>
Swift SVN r19469
We need to admit a potential inout-to-pointer conversion even if the inout references an array, because we can have pointers to arrays. Add a short-circuit so that array-to-pointer conversions always beat inout-to-pointer conversions; both solutions could otherwise be considered valid for an UnsafePointer<Void>, and passing a pointer to the array reference rather than to the array data would be very bad.
Swift SVN r19270
Add primitive type-checker rules for pointer arguments. An UnsafePointer argument accepts:
- an UnsafePointer value of matching element type, or of any type if the argument is UnsafePointer<Void>,
- an inout parameter of matching element type, or of any type if the argument is UnsafePointer<Void>, or
- an inout Array parameter of matching element type, or of any type if the argument is UnsafePointer<Void>.
A ConstUnsafePointer argument accepts:
- an UnsafePointer, ConstUnsafePointer, or AutoreleasingUnsafePointer value of matching element type, or of any type if the argument is ConstUnsafePointer<Void>,
- an inout parameter of matching element type, or of any type if the argument is ConstUnsafePointer<Void>, or
- an inout or non-inout Array parameter of matching element type, or of any type if the argument is ConstUnsafePointer<Void>.
An AutoreleasingUnsafePointer argument accepts:
- an AutoreleasingUnsafePointer value of matching element type, or
- an inout parameter of matching element type.
This disrupts some error messages in unrelated tests, which is tracked by <rdar://problem/17380520>.
Swift SVN r19008
Semantically, these expressions handle the same thing: an upcast of a
collection when the underlying element types of the source are
subtypes of or can be bridged to subtypes of the destination. This
reduces some branching in the type checker and eliminates duplication
in SILGen.
Swift SVN r18865
One difficulty in generating reasonable diagnostic data for type check failures has been the fact that many constraints had been synthesized without regard for where they were rooted in the program source. The result of this was that even though we would store failure information for specific constraints, we wouldn't emit it for lack of a source location. By making location data a non-optional component of constraints, we can begin diagnosing type check errors closer to their point of failure.
Swift SVN r18751
We removed this feature when we changed casting syntax, but left it in
the type checker to help migrate code via a Fix-It. We no longer need
it.
Swift SVN r18729
- Continue adding support for checked downcasts of array types (rdar://problem/16535104)
- Fix non-bridged array conversions post-r17868
- Fix rdar://problem/16773693
- Add tests for NSArray coercions to and from Array<T>
Swift SVN r17957
Introduce a new locator kind for argument/parameter comparisons that
tracks both the argument and the parameter, which we will eventually
use in diagnostics more regularly. For now, this helps us smooth over
scalar-to-tuple/tuple-to-tuple/tuple-to-scalar nonsense when dealing
with calls.
Fix a pile of fallout from this change.
Swift SVN r17648
Another baby step toward <rdar://problem/14462349>, made even more
tepid by the fact that I've quarantined this behind a new flag,
-strict-keyword-arguments. Enforcing this breaks a lot of code, so I'd
like to bring up the new model on the side (with good diagnostics that
include Fix-Its) before trolling through the entire standard library
and testsuite to fix violations of these new rules.
Swift SVN r17143
Introduce some infrastructure that allows us to speculatively apply
localized fixes to expressions during constraint solving to fix minor
typos and omissions. At present, we're able to introduce the fixes
during constraint simplification, prefer systems with fewer fixes when
there are multiple fixes, and diagnose the fixes with Fix-Its.
Actually rewriting the AST to reflect what the Fix-Its are doing is
still not handled.
As a start, introduce a fix that adds '()' if it appears to have been
forgotton, producing a diagnostic like this if it works out:
t.swift:8:3: error: function produces expected type 'B'; did you mean
to call it with '()'?
f(g)
^
()
Note that we did regress in one test case
(test/NameBinding/multi-file.swift), because that diagnostic was
getting lucky with the previous formulation.
Swift SVN r16937
Language features like erasing concrete metatype
values are also left for the future. Still, baby steps.
The singleton ordinary metatype for existential types
is still potentially useful; we allow it to be written
as P.Protocol.
I've been somewhat cavalier in making code accept
AnyMetatypeType instead of a more specific type, and
it's likely that a number of these places can and
should be more restrictive.
When T is an existential type, parse T.Type as an
ExistentialMetatypeType instead of a MetatypeType.
An existential metatype is the formal type
\exists t:P . (t.Type)
whereas the ordinary metatype is the formal type
(\exists t:P . t).Type
which is singleton. Our inability to express that
difference was leading to an ever-increasing cascade
of hacks where information is shadily passed behind
the scenes in order to make various operations with
static members of protocols work correctly.
This patch takes the first step towards fixing that
by splitting out existential metatypes and giving
them a pointer representation. Eventually, we will
need them to be able to carry protocol witness tables
Swift SVN r15716
This saves ~25% parsing time on the standard library and takes the
test case from <rdar://problem/16362184> from 5m32s down to
0.28s. There's a regression here when the generic form of an operator
is actually the best match, filed as <rdar://problem/16424438>.
Swift SVN r15468
