This patch adds the beginning of building the type refinement context tree for
availability checking in Sema, guarded by by the
-enable-experimental-availability-checking option. This tree parallels the AST
but is much more sparse: we introduce a new TypeRefinementContext only when
needed. Each context refines the range of potential OS versions that could be
encountered at run time. For the moment, we only refine contexts for function
bodies. I will add refinement contexts for #os(...) in a later commit.
The AST is not directly connected to the TRC tree except at the SourceFile
level; when type checking, we use source locations to look up the TRC
corresponding to an AST element. For the moment, we emit a diagnostic when the
programmer references a potentially unavailable declaration. We will later
change this to treat the declaration as if it had optional type.
Swift SVN r22145
The initializer requirement is causing too much exponential behavior
in the constraint solver. We'll have to address that
first. Re-instating this change is tracked by rdar://problem/18381811.
Swift SVN r22080
With this, we're now using initializer requirements rather than
"convertFromXXX" requirements everywhere, addressing the rest of
rdar://problem/18154091.
Swift SVN r22078
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
This patch adds a new 'pound_os' token, a new case for it in parseExprPostfix, and parsing of platform version constraints, e.g., OSX >= 10.10.
It also adds enough type checking and SILGen to get the parsing tests to run without triggering "Unimplemented" assertions.
Swift SVN r21865
This commit adds a new expression (AvailabilityQueryExpr) and a single kind of
specification for when a block of code or function is available
(VersionConstraintAvailabilitySpec). We may add more kinds of specifications
in the future. At the moment, the AvailabilityQueryExpr allows only a
single platform to be queried; I will add support for multiple platforms
in a later commit.
This commit contains just the added AST nodes; no parsing, type checking, etc.
I’ve added assert(false && “Unimplemented”) for places where support for
AvailabilityQueryExpr will need to be added later.
Swift SVN r21760
If either parameter to == has a known concrete type at constraint generation
time, see if that type is a nominal that can derive its conformance to
Equatable. If so, do so, and then add that == to the overload set.
(It may already be there, but that's okay -- it will get uniqued later.)
This isn't perfect because it relies on one of the parameters to == having
a concrete type /before/ constraint solving. There are plenty of reasons
why that wouldn't happen. But this at least fixes the common case, and
breaking the expression up into multiple lines is a less distasteful
workaround than replacing (x == .Value) with !(x != .Value). I've added a
test case that should work but doesn't that we can revisit later.
rdar://problem/18073705
Swift SVN r21557
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
We only want to apply the "favored constraint" optimization to symmetric binary operators. This helps prevent the pool of favored constraints from growing so large that it becomes ineffective. (rdar://problem/18008088)
Swift SVN r21184
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
We now provide fixits for if-expressions, point out the actual conditional expression (as opposed to the surrounding expression),
support unary '!' applications and avoid printing type variables in the diagnostic.
Swift SVN r20992
When -enable-optional-lvalues is active, type-check '?' operations like '!' operations, using an OptionalObject constraint to match the optional subexpression type to the non-optional result type of equivalent lvalue-ness.
Swift SVN r20610
I'll reuse the EnableOptionalLValues option to stage in work on lvalue support for '?' and AnyObject lookup, but remove the conditionals on '!'.
Swift SVN r20270
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
This addresses or improves several existing TC perf bugs (rdar://problem/15933674, rdar://problem/17110608, rdar://problem/17240816, rdar://problem/17244974), and seems to speed up our unit test runs by ~5%. (On my MacBook Pro, total average execution time is reduced from 557.28s to 531.89s.)
Swift SVN r19939
Mechanically add "Type" to the end of any protocol names that don't end
in "Type," "ible," or "able." Also, drop "Type" from the end of any
associated type names, except for those of the *LiteralConvertible
protocols.
There are obvious improvements to make in some of these names, which can
be handled with separate commits.
Fixes <rdar://problem/17165920> Protocols `Integer` etc should get
uglier names.
Swift SVN r19883
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
JoeP helped tweak things to ensure that pointer conversions are still
considered, but we no longer need the disjunction on InOutExprs to accommodate
user-defined inout conversions.
This causes some regressions in error reporting:
<rdar://problem/17489983> inout type mismatches complain about '@lvalue inout T'
<rdar://problem/17489894> inout not rejected as operand to assignment operator
Swift SVN r19306
We no longer need this language feature. The Sema support is still skeletally kept in place because removing it seems to totally break pointer conversions; I need to work with Joe and Doug to figure out why that's the case.
Swift SVN r19289
Previously, a forced downcast was implemented as a conditional
downcast following by an implicit unwrap, and relied on peephole
optimizations (in both constraint application and SILGen) to turn them
into a forced downcast. However, these didn't kick in for AnyObject ->
T[] downcasts, bypassing the more-efficient deferred checking our
native collections can do. Finishes <rdar://problem/17319154>.
Swift SVN r19064
This means that we'll get deferred checking of array and dictionary
downcasts when writing "arr as Derived[]",
"(dict as? Dictionary<DerivedKey, DerivedValue>)!", etc, when the
collection can do so.
This is both a general optimization and also staging for
<rdar://problem/17319154>.
Swift SVN r18975
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
There's a bit of a reshuffle of the ExplicitCastExpr subclasses:
- The existing ConditionalCheckedCastExpr expression node now represents
"as?".
- A new ForcedCheckedCastExpr node represents "as" when it is a
downcast.
- CoerceExpr represents "as" when it is a coercion.
- A new UnresolvedCheckedCastExpr node describes "as" before it has
been type-checked down to ForcedCheckedCastExpr or CoerceExpr. This
wasn't a strictly necessary change, but it helps us detangle what's
going on.
There are a few new diagnostics to help users avoid getting bitten by
as/as? mistakes:
- Custom errors when a forced downcast (as) is used as the operand
of postfix '!' or '?', with Fix-Its to remove the '!' or make the
downcast conditional (with as?), respectively.
- A warning when a forced downcast is injected into an optional,
with a suggestion to use a conditional downcast.
- A new error when the postfix '!' is used for a contextual
downcast, with a Fix-It to replace it with "as T" with the
contextual type T.
Lots of test updates, none of which felt like regressions. The new
tests are in test/expr/cast/optionals.swift.
Addresses <rdar://problem/17000058>
Swift SVN r18556
Array downcast is an explicit cast written "x as U[]", not an implicit
conversion, so make it a subclass of ExplicitCastExpr. The only
effective change here is that we retain the location of the "as" and
the type as written in the AST. No semantic change.
Swift SVN r18391
checked cast expression.
We don't actually *use* that path for anything right now,
because we basically re-check the cast from scratch after
constraint application. This is nonetheless necessary to
avoid collisions with constraints which might be located
on the result, such as would arise in an initialization
context.
In particular, this patch fixes a crash arising when both
the operand and the result of a coercion require a
user-defined conversion. Test to follow.
Swift SVN r18386
we can represent such a thing.
This fixes: <rdar://problem/16655091> @IBOutlet should imply ImplicitlyUnwrappedOptional+weak by default
Swift SVN r18320
at the SIL level. Now, the referent type of a WeakStorageType is always
an optional type, instead of always being the underlying reference. This
allows us to represent both optional types. Before, both of these had the
same AST representation of WeakStorageType(T):
weak var x : T?
weak var x : T!
which doesn't work. Now we represent the optional type explicitly in the
AST and at SIL level. This also significantly simplifies a bunch of code
that was ripping off the optional type and resynthesizing it in other places,
and makes SILGen of weak pointers much more straight-forward by eliminating
the need for emitRefToOptional and emitOptionalToRef entirely (see the diffs
in test/SILGen/weak).
Weak pointers still have problems, but this is a big step forward.
Swift SVN r18312
String interpolation invokes convertFromStringInterpolationSegment() function
now. There is no need to add extensions to String to allow custom types to
participate in string interpolation. Just implementing Printable will do the
right thing.
Swift SVN r18104
PatternBindingDecls in capture lists and strip off the loadexprs
that are there. This resolves the type checker issues that were
afflicting weak captures and a couple of unowned cases.
Swift SVN r17861
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
