Type-check the parameter patterns and result type of a generic
function before assigning archetypes, which potentially produces a
dependent function type. Then, assign archetypes to the generic
parameters, revert all of the dependent types, and validate the types
again (now with archetypes), so the rest of the frontend can
(temporarily) continue to traffic in archetypes.
The type-check, revert, type-check behavior is a bit odd. We want to
re-process the TypeReprs because they have all of the source-location
information necessary to produce proper diagnostics, but from this
processing we will eventually need to produce two types: the type for
the signature (as viewed from the outside), which will involve generic
parameters, and the type for the definition, which will involve
archetypes.
Swift SVN r7504
At present, this is a distinction without a difference. However, it's
a step toward detangling archetypes from the interface of a
polymorphic function.
Swift SVN r7405
Previously, TypeAliasDecl was used for typealiases, generic
parameters, and assocaited types, which is hideous and the source of
much confusion. Factor the latter two out into their own decl nodes,
with a common abstract base for "type parameters", and push these
nodes throughout the frontend.
No real functionality change, but this is a step toward uniquing
polymorphic types, among other things.
Swift SVN r7345
A SuperRefExpr semantically includes an upcast, and coercing it to a deeper subclass by wrapping it in a DerivedToBaseExpr is redundant and confuses SILGen. Instead, update the type of the SuperRefExpr directly before loading from it. Fixes <rdar://problem/14581294>.
Swift SVN r6720
Standardize on the more-common "superclass" and "subclass" terminology
throughout the compiler, rather than the odd mix of base/derived and
super/sub.
Also, have ClassDecl only store the Type of the superclass. Location
information will be part of the inheritance clause for parsed classes.
Swift SVN r6687
This makes long literals like 1_000_000_000 or 0x7FFF_FFFF_FFFF_FFFF much easier to read, and has precedent in Perl, OCaml, Python, Ruby, Rust, ... Fixes <rdar://problem/14247571>.
Swift SVN r6681
-Introduce PersistentParserState to represent state persistent among multiple parsing passes.
The advantage is that PersistentParserState is independent of a particular Parser or Lexer object.
-Use PersistentParserState to keep information about delayed function body parsing and eliminate parser-specific
state from the AST (ParserTokenRange).
-Introduce DelayedParsingCallbacks to abstract out of the parser the logic about which functions should be delayed
or skipped.
Many thanks to Dmitri for his valuable feedback!
Swift SVN r6580
There is a bunch of copy-and-paste here from the tuple-shuffle
code. The expected trajectory is that ScalarToTupleExpr will grow into
a general TupleConversionExpr, obviating the need for TupleShuffleExpr
entirely and eliminating the redundancy.
Swift SVN r6347
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 change switches SIL generation for default values over to using
the default argument generators we started emitting in r6258. Note
that we don't use these entry points for default arguments involving
__FILE__, __LINE__, or __COLUMN___. These will need a different kind
of magic.
Swift SVN r6295
When we form a tuple that uses default arguments, find the source of
the default arguments (which will be a function or constructor
declaration). This information will eventually be introduced into the
AST.
Swift SVN r6277
* Added a mode in swift-ide-test to test code completion. Unlike c-index-test,
the code completion token in tests is a real token -- we don't need to
count lines and columns anymore.
* Added support in lexer to produce a code completion token.
* Added a parser interface to code completion. It is passed down from the
libFrontend to the parser, but its functions are not called yet.
* Added a sketch of the interface of code completion consumer and code
completion results.
Note: all this is not doing anything useful yet.
Swift SVN r6128
When the name of a generic type is referenced, without any generic
arguments, within the definition of a generic type (or extensions of
that generic type), use the generic arguments provided by that
context. Thus, within the definition of X<T> below, one can simply use
'X' as a shorthand for 'X<T>':
class X<T> {
func swap(other : X) { /* ... */ } // same as "func swap(other : X<T>)"
}
This resolution provides essentially the same behavior as the
injected class name does in C++. Note that this rule overrides any
inference rules, such that (for example) the following is ill-formed
rather than inferring the generic arguments of 'X':
class X<T> {
func foo() {
var xi : X<Int> = X()
}
}
Note that name binding has changed slightly: when unqualified lookup
finds a type declaration within a nominal type, it is now treated as
a DeclRefExpr (or overloaded variant thereof) rather than as a member
access with an implicit 'this'.
Fixes <rdar://problem/14078437>.
Swift SVN r6049
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
In order to do this, we need to save and restore parser state easily. The
important pieces of state are:
* lexer position;
* lexical scope stack.
Lexer position can be saved/restored easily. We don't need to store the tokens
for the function body because swift does not have a preprocessor and we can
easily re-lex everything we need. We just store the lexer state for the
beginning and the end of the body.
To save the lexical scope stack, we had to change the underlying data
structure. Originally, the parser used the ScopedHashTable, which supports
only a stack of scopes. But we need a *tree* of scopes. I implemented
TreeScopedHashTable based on ScopedHashTable. It has an optimization for
pushing/popping scopes in a stack fashion -- these scopes will not be allocated
on the heap. While ‘detached’ scopes that we want to re-enter later, and all
their parent scopes, are moved to the heap.
In parseIntoTranslationUnit() we do a second pass over the 'structural AST'
that does not contain function bodies to actually parse them from saved token
ranges.
Swift SVN r5886
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
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
Sub-patterns are now considered part of the enclosing pattern, so if the
parent pattern pointer is const, the child pointer will be too.
I changed the minimal number of files to make this work, but future code
should use "const Pattern *" when intended, and "Pattern *" only if they
intend to modify the pattern.
Swift SVN r5743
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
Trailing closure syntax allows one to write a closure following any
other postfix expression, which passes the closure to that postfix
expression as an arguments. For example:
sort(fruits) { |lhs, rhs|
print("Comparing \(lhs) to \(rhs)\n")
return lhs > rhs
}
As a temporary limitation to work around the ambiguity with
if foo { ... } { ... }
we require trailing closures to have an explicit parameter list, e.g.,
if foo { || ... } { ... }
Swift SVN r5210
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
We will handle Swift-function-to-ObjC-block bridging in SILGen as part of general Cocoa-to-Swift type bridging. Temporarily disable building swiftAppKit and tests that exercise block bridging until the new implementation lands.
Swift SVN r5090
There is a special-case hack to allow capture of 'this', which is
implicitly [byref] for structs. At the moment, most of the cases where
this hack is necessary are [auto_closure] parameters (for assertions
and &&/||).
Swift SVN r5047
Make IntegerLiteral, FloatLiteral, and StringLiteral own their own copies of their values so they don't depend on the AST. Remove the now-redundant IntegerValueInst, which only existed to be a non-AST-dependent variant of IntegerLiteral.
Swift SVN r5045
Fixes <rdar://problem/13723781>.
T(x) still has some lingering conversion behavior, so there's a type-checking ambiguity in classes that are constructible from super- or subclasses, like stdlib's File is from VFSObject. I cheesed around this for now by using keywords in the constructor forms that have ambiguities. This issue should go away when we finish making T(x) mean only construction.
Swift SVN r5002
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
