This introduces a new pattern, spelled "x?" which is sugar for
matching ".Some(x)". It also changes the parser slightly so that
_ (the discard expr) is parsed as a unary expr instead of as an
expr. This allows it to have postfix ? after it, which is important
in pattern contexts to support "case _?:".
Swift SVN r25907
Curried function parameters (i.e., those past the first written
parameter list) default to having argument labels (which they always
have), but any attempt to change or remove the argument labels would
fail. Use the fact that we keep both the argument labels and the
parameter names in patterns to generalize our handling of argument
labels to address this problem.
The IDE changes are due to some positive fallout from this change: we
were using the body parameters as labels in code completions for
subscript operations, which was annoying and wrong.
Fixes rdar://problem/17237268.
Swift SVN r24525
type-checking and applying attributes.
We should really move to a model where variables are
type-checked in a single pass, including their attributes.
However, given that we don't, attributes which affect the
type must be applied in multiple places and hence multiple
times to the same declaration.
Swift SVN r16339
Parse the new function syntax, which allows both the argument (API)
and parameter (internal) name to be specified prior to the colon
within each parameter. Don't re-use the existing pattern-parsing
logic. Rather, implement a new (far simpler) parser for this purpose,
then map from its simple data structures to ArgParams and BodyParams
as we're used to.
There are a number of caveats here:
- We no longer have the ability to use patterns for parameters in
function declarations. The only place this really has an impact is
that it makes the ~> hack in the standard library even uglier.
- This exposed some issues with code completion with generic
parameters that need to be investigated.
- There's still some work to be done to improve recovery when things
parse poorly within a parameter list; there are some XFAILs to deal
with that.
I'll address the last two issues with follow-up commits.
Swift SVN r15967
Allow a form of 'case is T' that matches the cast result to a subpattern, 'case <pattern> as T'. This exposes an issue in switch destructuring with casting into complex class hierarchies <rdar://problem/16401831> but works for common cases.
Swift SVN r15396
Previously, we were cloning the default arguments completely, which
meant code duplication (when inheriting within a module) or simply a
failure (when inheriting across modules). Now, we reference the
default arguments where we inherited them, eliminating the
duplication. Part of <rdar://problem/16318855>.
Swift SVN r15062
Introduce a new Pattern::forEachVariable that takes a lambda and iterates
over all the variables encompassed by the pattern (the ones found by
collectVariables) and runs the lambda on it.
Use this to implement collectVariables, so we only have one copy of the code.
Convert several places to use this, removing a bunch of duplicated code for
walking the pattern structure and extracting decls.
Convert a few uses of collectVariables to forEachVariable, leading to more
clear code without a temporary smallvector.
Remove simplifyPatternTypes in CSApply.cpp, which is dead.
Swift SVN r13545
Change Pattern::getBoundName to look through VarPatterns,
which means that the presence of var/let in an argument list no longer
change the mangling of the function.
Swift SVN r11780
are not settable (like get-only ones). Set the 'isLet' bit in various
places, but not the particularly interesting or useful places yet.
Swift SVN r11121
This allows us to say roughly what generic type we want without having
to specify all of the details, e.g.,
var dict : Dictionary = ["Hello" : 1, "World" : 2]
// infers Dictionary<String, Int>
Fixes <rdar://problem/14238814>.
Swift SVN r9678
Instead of relying on the subpattern being a well-formed TuplePattern, let's track our own subelements so we can associate them to properties and validate them ourselves.
Swift SVN r8771
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
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
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
The semantics of varargs (only for the last element) make it more appropriate as a property of the TuplePattern.
Also free the Parser from needing to construct synthetic types (ArraySlice for type of vararg element) to
accommodate the TypeChecker and move the logic to the TypeChecker. This will be more beneficial when the parser stops
creating types in general.
Swift SVN r6271
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
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
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
