Teach TuplePatternElt to keep track of the kind of the default
argument: none, normal (provided by calling into the appropriate
callee generator), __FILE__, __LINE__, or __COLUMN__. For the latter
three cases, the type checker forms the appropriate argument as part
of the call.
The actual default argument expression will only be held in the tuple
pattern element when we've parsed it; it won't be serialized or
deserialized, because only the defining module cares. This is a step
toward eliminate the initialization expression from tuple types.
The extension to TupleShuffleExpr is a hack, which will also be
replicated in ScalarToTupleExpr, until we finally rework the
representation of TupleShuffleExpr (<rdar://problem/12340004>).
Swift SVN r6299
This the first part for improving source location fidelity for types,
changes to follow:
-The Parser will not create any types, it will just create TypeReprs.
-The type checker will create the types by going through TypeReprs.
-IdentifierType will be removed.
Swift SVN r6112
The idea for now is that this is a SIL-only type used for
representing the storage of a weak or unowned reference.
Having it be its own type is pretty vital for reasonable
behavior in SIL and IR-generation, and it's likely that
this will surface into runtime metadata as well (hence
the mangling).
I've implemented a bunch of things that technically I don't
think are necessary if this stays out of the typechecker,
but it's easier to implement half-a-dozen "recurse into
the child type" methods now that it would be to find them
all later if we change our minds.
Swift SVN r6091
When we are interpreting escape sequences in the lexer, we copy the string
literal bytes to ASTContext instead of storing a pointer to the source buffer.
But then we used to try to get a source location for that string in the heap,
which is not a valid source buffer. It succeeds during parsing, but breaks
when we try to print a diagnostic using this location.
Added a verifier check for this.
Also added a real source range for StringLiteralExpr, instead of a source range
with begin == end, produced from the beginning location.
Swift SVN r5961
A single case block can have one or more 'case ...:' labels. 'case' labels contain patterns instead of exprs. 'default:' is a funny spelling for 'case _:'. Change the CaseStmt representation and rip out all the parsing, type-checking, and SILGen built off the old representation.
Swift SVN r5795
Improve our representations of casts in the AST and SIL so that 'as!' and 'is' (and eventually 'as?') can share almost all of the same type-checking, SILGen, and IRGen code.
In the AST, we now represent 'as!' and 'is' as UnconditionalCheckedCastExpr and IsaExpr, respectively, with the semantic variations of cast (downcast, super-to-archetype, archetype-to-concrete, etc.) discriminated by an enum field. This keeps the user-visible syntactic and type behavior differences of the two forms cleanly separated for AST consumers.
At the SIL level, we transpose the representation so that the different cast semantics get their own instructions and the conditional/unconditional cast behavior is indicated by an enum, making it easy for IRGen to discriminate the different code paths for the different semantics. We also add an 'IsNonnull' instruction to cover the conditional-cast-result-to-boolean conversion common to all the forms of 'is'.
The upshot of all this is that 'x is T' now works for all the new archetype and existential cast forms supported by 'as!'.
Swift SVN r5737
Change AssignStmt into AssignExpr; this will make assignment behave more consistently with assignment-like operators, and is a first step toward integrating '=' parsing with SequenceExpr resolution so that '=' can obey precedence rules. This also nicely simplifies the AST representation of c-style ForStmts; the initializer and increment need only be Expr* instead of awkward Expr*/AssignStmt* unions.
This doesn't actually change any user-visible behavior yet; AssignExpr is still only parsed at statement scope, and typeCheckAssignment is still segregrated from the constraint checker at large. (In particular, a PipeClosureExpr containing a single assign expr in its body still doesn't use the assign expr to resolve its own type.) The parsing issue will be addressed by handling '=' during SequenceExpr resolution. typeCheckAssignment can hopefully be reworked to work within the constraint checker too.
Swift SVN r5500
Technically, they are always canonical, but so are oneof/struct/class
types, and we don't classify them as "always canonical" because we
typically want to give them special semantics. Eliminates an
embarrassing bug wherein we couldn't handle conversion of
existentials.
Swift SVN r5289
Whether or how the condition of a ternary expression type-checks is a
separate problem from the then/else branches of the ternary
expression. Actually treat it as such.
This eliminates the last place in the frontend where we mode-switch
into the old type checker intentionally. It's still used in various
places externally in the test suite (via -no-constraint-checker) and
implicit (e.g., via calls to semaApplyExpr).
Swift SVN r5285
This commit implements closure syntax that places the (optional)
parameter list in pipes within the curly braces of a closure. This
syntax "slides" well from very simple closures with anonymous
arguments, e.g.,
sort(array, {$1 > $0})
to naming the arguments
sort(array, {|x, y| x > y})
to adding a return type and/or parameter types
sort(array, {|x : String, y : String| -> Bool x > y})
and with multiple statements in the body:
sort(array, {|x, y|
print("Comparing \(x) and \(y)\n")
return x > y
})
When the body contains only a single expression, that expression
participates in type inference with its enclosing expression, which
allows one to type-check, e.g.,
map(strings, {|x| x.toUpper()})
without context. If one has multiple statements, however, one will
need to provide additional type information either with context
strings = map(strings, {
return $0.toUpper()
})
or via annotations
map(strings, {|x| -> String
return x.toUpper()
}
because we don't perform inter-statement type inference.
The new closure expressions are only available with the new type
checker, where they completely displace the existing { $0 + $1 }
anonymous closures. 'func' expressions remain unchanged.
The tiny test changes (in SIL output and the constraint-checker test)
are due to the PipeClosureExpr AST storing anonymous closure arguments
($0, $1, etc.) within a pattern in the AST. It's far cleaner to
implement this way.
The testing here is still fairly light. In particular, we need better
testing of parser recovery, name lookup for closures with local types,
more deduction scenarios, and multi-statement closures (which don't
get exercised beyond the unit tests).
Swift SVN r5169
Start factoring out the logic that computes the mapping from one tuple
type to another. We're only using it in one place now (the
tuple-to-tuple coercion), but it should be picked up by the constraint
checker's type-matching code.
Also, fix the temporary statistics covering how much is going through
the old coercion code. With this change, we're only missing 40 of 4548
of the coercions in swift.swift (all of which appear to be string
interpolations, function type conversions, or user-defined
conversions).
Swift SVN r5087
Validating the type ensures that we collect all of the
protocol-conformance bindings we need for the bound generic
types. Additionally, check that BoundGenericTypes have exactly the
right number of arguments, which would have caught the bug fixed in
r5050.
Fixes <rdar://problem/13818785>.
Swift SVN r5062
Most of this is mechanical, because we weren't actually relying on
byref(heap) for anything. Simplify capture analysis, now that the only
way a variable can have non-fixed lifetime is if it is actually
captured. Fixes <rdar://problem/11247831>.
Swift SVN r5046
One can now attach an initializer to a member variable. That value
will used as the default initialization for the member variable(s) it
initializes. Fixes <rdar://problem/12597404>.
Swift SVN r4989
When the struct definition has no user-defined constructors, and there
is at least one instance variable, add an implicit default
constructor. This default constructor is currently empty; that's to be
fixed next.
Swift SVN r4868
Provide distinct syntax 'a as T' for coercions and 'a as! T' for unchecked downcasts, and add type-checker logic specialized to coercions and downcasts for these expressions. Change the AST representation of ExplicitCastExpr to keep the destination type as a TypeLoc rather than a subexpression, and change the names of the nodes to UncheckedDowncast and UncheckedSuperToArchetype to make their unchecked-ness explicit and disambiguate them from future checked casts.
In order to keep the changes staged, this doesn't yet affect the T(x) constructor syntax, which will for the time being still perform any construction, coercion, or cast.
Swift SVN r4498
Now that we don't allow static methods to be invoked from instances we no longer need an AST node to represent an implicit instance-to-metatype conversion. MetatypeExpr encodes the explicit '.metatype' operation.
Swift SVN r4472
In the StmtChecker, consider a ConstructorDecl or DestructorDecl context to be a function context that returns (). In IRGen for constructors and destructors, set up proper return blocks so that 'return' does the right thing, and in constructors, pretend that the body has no return value even though the underlying constructor mechanism totally returns a value. Fixes <rdar://problem/12950817>.
Swift SVN r3915
In particular, fix a bug where DREs that refer to types were
always given trivial reps because we were trying to emit the
metatype's metatype. This in turn exposes a number of bugs,
including a typechecker bug (where GetMetatypeExpr bases
weren't converted to r-values) and a bug where MREs that
refer to types were always assumed to produce trivial reps.
Swift SVN r3095
We'll want a superclass pointer on ClassType and BoundGenericClassType,
and this also makes it easier to detect both kinds of class type.
Swift SVN r3061
conversions on metatypes; at runtime it has no effect,
since those conversions are always trivial. Fix a number
of bugs involving the conversion of metatypes, in both
typecheckers.
Swift SVN r3055
Introduce a '.metatype' form in the syntax and do some basic
type-checking that I probably haven't done right. Change
IR-generation for that and GetMetatypeExpr to use code that
actually honors the dynamic type of an expression.
Swift SVN r3053
since we're now applying solved constraints to an expression to
produce a well-typed expression. The resulting expressions are now
returned and run through the verifier, so deal with some of the
byref(implicit) fallout.
Swift SVN r2835
a reliable way to track whether a particular type has been
validated. Instead, add some bits to the type to indicate which stage
of checking it has received. I hate it, but it works and I don't know
of a better way to ensure that types get validated. This subsystem
will need to get rearchitected at some point (ugh).
Reduce the number of places where we build new BoundGenericTypes,
since they need to be validated fully to get substitutions, and then
introduces a number of validateTypeSimple() calls to validate types in
places where we know the validation will succeed, but we need that
information regardless.
Swift SVN r2681
parameters we're substituting. This is either "all levels" (when we're
substituting a specific base type in a member access) or "the
innermost level" (when we're substituting after deducing from a use or
application of a polymorphic function).
Swift SVN r2576
This is much more convenient for IRGen, and gives us a reasonable representation for a static
polymorphic function on a polymorphic type.
I had to hack up irgen::emitArrayInjectionCall a bit to make the rest of this patch work; John, please
revert those bits once emitCallee is fixed.
Swift SVN r2488
in SpecializeExpr, so that we have complete substitution and
protocol-conformance information. On the IR generation side, pass
witness tables for all of the archetypes (again, including derived
archetypes) into generic functions, so that we have witness tables for
all of the associated types.
There are at least two major issues:
(1) This is a terribly inefficient way to pass witness tables for
associated types. The witness tables for associated types should be
accessible via the witness tables of their parent. However, we need
more information in the ASTs here, because there may be additional
witness tables that will need to be passed for requirements that are
placed on the associated type by the generic function itself.
(2) Something about my test triggers a void/non-void verification failure
in the witness build for an instance function whose abstracted form
returns an associated type archetype and whose concrete form returns
an empty struct. See the FIXME in the test.
Swift SVN r2464
and derived) so they can be stored within the generic parameter list
for use 'later'.
More immediately, when we deduce arguments for a polymorphic function
type, check that all of the derived archetypes conform to all of the
protocol requirements, stashing that protocol-conformance information
in the coercion context (also for use 'later'). From a type-checking
perspective, we now actually verify requirements on associated types
such as the requirement on R.Element in, e.g.,
func minElement<R : Range requires R.Element : Ordered>(range : R)
-> R.Element
Swift SVN r2460
used in the very narrow case where we were converting from one
protocol type to another (super) protocol type. However, ErasureExpr
now handles this case via its null conformance entries (for the
"trivial" cases), and can cope with general existential types where
some conversions are trivial and others are not.
The IR generation side of this is basically just a hack to inline the
existing super-conversion code into the erasure code. This whole
routine will eventually need to be reworked anyway to deal with
destination types that are protocol-conformance types and with source
types that are archetypes (for generic/existential interactions).
Swift SVN r2213
