MemberRefExpr now uses ConcreteDeclRef to refer to its member, which
includes the substitutions and obviates the need for
GenericMemberRefExpr.
Swift SVN r7842
When performing member lookup into an existential that involves the
DynamicLookup protocol, look into all classes and protocols for that
member. References to anything found via this lookup mechanism are
returned as instances of Optional.
This introduces the basic lookup mechanics into the type
checker. There are still numerous issues to work through:
- Subscripting isn't supported yet
- There's no SILGen or IRGen support
- The ASTs probably aren't good enough for the above anyway
- References to generics will be broken
- Ambiguity resolution or non-resolution
Thanks to Jordan for the patch wiring up DynamicLookup.
Swift SVN r7689
Also make the implicit AssociatedTypeDecl, created for a protocol, to have the
location of its protocol, otherwise the verifier will complain that a decl has no
source range.
Swift SVN r7673
a syntax error. Usually the type parsing can just return nullptr for the
TypeRepr, but when we want to construct an AST node that should have included
that type, we should provide a non-null TypeRepr.
Swift SVN r7375
ForStmt::Cond is already a NullablePtr<>. This patch changes
ForStmt::Initializer and ForStmt::Increment to be NullablePtr. Otherwise it
looks like Cond can be null, while Initializer and Increment can not.
Swift SVN r7265
The only visible change from this now is that diagnostics will come in
a more sensible order, because we do name resolution along with the
rest of type checking, rather than in a separate pass early
on. However, it's foundational for lazy type checking, type
refinement, and various other important features and bug fixes.
Swift SVN r7086
We haven't fully updated references to union cases, and enums still are not
their own thing yet, but "oneof" is gone. Long live "union"!
Swift SVN r6783
This eliminates the odd separate pass over default arguments, as well
as the isFirstPass distinction for type checking patterns,
centralizing default argument checking. It actually regresses us
slightly (see <rdar://problem/14488311>) due to name binding happening
too early (and, therefore, in the wrong context). This will be fixed
by moving name binding into constraint generation.
Swift SVN r6368
If we see '.Foo' or '.Foo(...)' in a case, resolve it as a OneOfElementPattern with element to be determined at type-checking time. If we see 'A.B' or 'A.B(...)', try to resolve 'A.B' as a qualified reference to a OneOfElementDecl, and resolve the expression as a OneOfElementPattern referencing that decl if we find one. During type-checking, resolve the element decl for unresolved OneOfElementPatterns, then match the subpattern to the type of the element's associated data (or void if it has none).
A few cases don't yet work right that ought to:
- Qualified references to generic oneof cases with generic arguments elided, e.g. 'case Optional.None:'
- Qualified references to generic oneof cases through a module, e.g. 'case swift.Optional<Int>.None:'
Swift SVN r6278
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
Sema knows better how to call getLogicValue to get an i1 from a conditional than SILGen does. Fake up a placeholder variable we can slot into a 'expr ~= var' expression, and have the type-checker run on the entire apply expr to generate getLogicValue() conversions on the applied result.
Swift SVN r5995
Create a scope for each case block to contain bindings from its patterns, and invoke addVarsToScope after parsing case label patterns to introduce vars into that scope. Refactor addVarsToScope to use an ASTWalker so it finds pattern vars embedded in expr patterns.
Swift SVN r5899
Because of '~=' lookahead and precedence parsing, we need to be able to parse pattern productions in expression position and validate them after name binding. Add an unresolved Expr node that can hold a subpattern for this purpose.
Swift SVN r5825
We decided to go with 'var' as a distributive pattern introducer which applies to bare identifiers within the subpattern. For example, 'var (a, b)' and '(var a, var b)' would be equivalent patterns. To model this, give 'var' its own AST node with a subpattern and remove the introducer loc from NamedPattern.
Swift SVN r5824
I talked to John about parsing patterns today, and because of the magnitude of name-lookup-dependent ambiguities between patterns and expressions, we agreed that at least for a first-pass implementation it makes sense to parse patterns as extensions of the expr grammar and charge name binding with distinguishing patterns from expressions. This gets us out of needing the concept of an "unresolved pattern", at least in the short term.
Swift SVN r5808
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
Introduce Pattern subclasses for the 'is T', 'T(<pattern>)', and '<expr>' pattern syntaxes we'll be introducing for pattern-matching "switch" statements. Also add an 'UnresolvedCalLPattern' to act as an intermediate for name lookup to resolve to a nominal type, oneof element, or function call expression pattern. Since we'll need to be able to rewrite patterns like we do expressions, add setters to AST nodes that contain references to subpatterns. Implement some basic walking logic in places we search patterns for var decls, but punt on any more complex type-checking or SILGen derived from these nodes until we actually use them.
Swift SVN r5780
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
Open us 'a as! T' to allow dynamic casts from archetypes to archetypes, archetypes to concrete types, existentials to archetypes, and existentials to concrete types. When the type-checker finds these cases, generate new Unchecked*To*Expr node types for each case.
We don't yet check whether the target type actually makes sense with the constraints of the archetype or existential, nor do we implement the SILGen/IRGen backends for these operations. We also don't extend 'x is T' to query the new operation kinds. There's a better factoring that would allow 'as!' and 'is' to share more code. For now, I want to make sure 'x as! T' continues to work for ObjC APIs when we flip the switch to import protocol types.
Swift SVN r5611
Treat 'as' and 'is' as fixed-precedence binary operators, like we now do '=' and '? ... :'. However, since 'as' and 'is' max-munch-parse a type name on their RHS, we only parse them at the tail end of a SequenceExpr. This not only makes 'a = b as T' work as expected again, but also makes 'a += b as T' work, fixing <rdar://problem/13772819>.
Swift SVN r5514
We can save some source code noise and ASTContext allocation traffic by representing unsequenced assignments and ternaries using AssignExpr/IfExpr with the left and right subnodes nulled out, filling them in during sequence folding.
Swift SVN r5509
Parse '=' as a binary operator with fixed precedence, parsing it into a temporary UnsequencedAssignExpr that gets matched to operands and turned into an AssignExpr during sequence expr folding. This makes '=' behave like library-defined assignment-like binary operators.
This temporarily puts '=' at the wrong precedence relative to 'as' and 'is', until 'as' and 'is' can be integrated into sequence parsing as well.
Swift SVN r5508
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
Instead of trying to parse '?' and ':' as separate placeholder exprs and matching them up during binary expr resolution, it's a bit cleaner to parse the entire '? ... :' middle expr of the ternary into a single placeholder node at parse time. Then binary expr resolution only ever has to consider a single sequence element.
Swift SVN r5499
Because we synthesize AST nodes fairly often, and those synthesized
AST nodes rarely have useful source-location information, we shouldn't
be using the validity of source locations to describe the AST. In the
case of closures, use a bit instead. No functionality change.
Swift SVN r5205
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
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
Give the ternary a fixed precedence, parse '?' and ':' into SequenceExprs, and fold them into IfExprs as part of sequence folding. This allows assignment operators like '+=' to have precedence below the ternary as in C. Fixes <rdar://problem/13756211>.
Swift SVN r4983
Add assignment statements into the implicitly-defined default
constructor body to initialize all of the members appropriately, e.g.,
by calling the default constructor. For builtin types and class types,
introduce ZeroValueInitExpr to produce a "zero" value.
ZeroValueInitExpr still needs a representation in SIL. Until then,
actual generation of this AST is suppressed.
Swift SVN r4895
Add an IsaInst to represent type tests, and implement SILGen for IsSubtypeExpr AST nodes. Get rid of SuperIsArchetypeExpr because it's not really necessary to have it different from IsaSubtype--the SIL and IR behavior is identical.
Swift SVN r4855
Create a new FallthroughStmt, which transfers control from a 'case' or 'default' block to the next 'case' or 'default' block within a switch. Implement parsing and sema for FallthroughStmt, which syntactically consists of a single 'fallthrough' keyword. Sema verifies that 'fallthrough' actually appears inside a switch statement and that there is a following case or default block to pass control to.
SILGen/IRGen support forthcoming.
Swift SVN r4653
Unfortunately, this regresses the repl when expressions like (1,2) are entered. This is because the repl is violating some invariants (forming dags out of ASTs, making ASDAG's which upset the type checker). I'm going to fix this next, but can't bring myself to do it in the same commit.
Swift SVN r4617
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
Implement the syntax 'if x then y else z', which evaluates to 'y' if 'x' is true or 'z' if 'x' is false. 'x' must be a valid logic value, and 'y' and 'z' must be implicitly convertible to a common type.
Swift SVN r4407
Implement switch statements with simple value comparison to get the drudge work of parsing and generating switches in place. Cases are checked using a '=~' operator to compare the subject of the switch to the value in the case. Unlike a C switch, cases each have their own scope and don't fall through. 'break' and 'continue' apply to an outer loop rather to the switch itself. Multiple case values can be specified in a comma-separated list, as in 'case 1, 2, 3, 4:'. Currently no effort is made to check for duplicate cases or to rank cases by match strength; cases are just checked in source order, and the first one wins (aside from 'default', which is branched to if all cases fail).
Swift SVN r4359
'super.constructor' shouldn't be referenceable without being called, and 'super.constructor(...)' shouldn't return a value. Require super.constructor expressions to be called at parse time, and wrap the call expression in a new RebindThisInConstructorExpr that represents consuming the delegated-to constructor by using it to reassign 'this'. This should theoretically allow super.constructor to an ill-behaved self-modifying ObjC class to work. It's also necessary to support delegating constructors of value types.
Swift SVN r4326
