The type checker (and various other parts of the front end) jump
through many hoops to try to cope with the lack of a proper
declaration for an inferred type witness, causing various annoying
bugs. Additionally, we were creating implicit declarations for
derived/synthesized witnesses, leading to inconsistent AST
representations. This ch
Note that we'll now end up printing the inferred type aliases for type
witnesses, which represents a reversal of the decision that closed
rdar://problem/15168378. This result is more consistent.
Now with a simpler accessibility computation.
Swift SVN r27512
The type checker (and various other parts of the front end) jump
through many hoops to try to cope with the lack of a proper
declaration for an inferred type witness, causing various annoying
bugs. Additionally, we were creating implicit declarations for
derived/synthesized witnesses, leading to inconsistent AST
representations. This ch
Note that we'll now end up printing the inferred type aliases for type
witnesses, which represents a reversal of the decision that closed
rdar://problem/15168378. This result is more consistent.
Swift SVN r27487
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
Previously the "as" keyword could either represent coercion or or forced
downcasting. This change separates the two notions. "as" now only means
type conversion, while the new "as!" operator is used to perform forced
downcasting. If a program uses "as" where "as!" is called for, we emit a
diagnostic and fixit.
Internally, this change removes the UnresolvedCheckedCastExpr class, in
favor of directly instantiating CoerceExpr when parsing the "as"
operator, and ForcedCheckedCastExpr when parsing the "as!" operator.
Swift SVN r24253
This change pulls the handling of the element pattern and sequence of
a for-each loop into a single constraint system, so that we get type
inference between the two. Among other things, this allows one to
infer generic arguments within the element pattern from the sequence's
element type as well as allowing type annotations or the form of the
element pattern to affect overload resolution and generic argument
deduction for the sequence itself.
Swift SVN r19721
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
