Previously some parts of the compiler referred to them as "fields",
and most referred to them as "elements". Use the more generic 'elements'
nomenclature because that's what we refer to other things in the compiler
(e.g. the elements of a bracestmt).
At the same time, make the API better by providing "getElement" consistently
and using it, instead of getElements()[i].
NFC.
Swift SVN r26894
This pushes tuple pattern labels forward:
- Actually record them in TuplePatternElt.
- Remove the tuple shuffle ban that prevents some cases
(e.g. the one in the radar) of a tuple with labels being shuffled
onto a tuple without labels.
- Remove dead code enabled by removing the restriction.
Swift SVN r26852
to represent them, and just dropped them on the ground. Now we parse them,
persist them in the AST, and "resolve" them from the expr grammar, but still
drop them on the ground. This is progress towards fixing: rdar://20135489
Swift SVN r26828
This patch introduces a new kind of pattern for matching bool literals, i.e. true and false. Essentially, it is very similar to a pattern for matching enum elements, but simpler. Most of the code is just a boiler plate code copy/pasted from the code for enum element patterns. The only different thing is the emitBoolDispatch function, which emits a SIL code for matching bools.
With this patch, we don't get any false non-exhaustive switch diagnostics for switches on bools anymore. And we have a lot of radars complaining about it. For example rdar://16514545 and rdar://20130240.
Note, that this patch fixes the non-exhaustive switch diagnostics without changing the internal representation of bools. Implementing bool as an enum would have the same effect when it comes to these diagnostics and we would get this diagnostics fix for free, i.e. without any code committed here. But implementing bools-as-enums is an ongoing work and I'm investigating its performance implications. If we become confident that bool-as-enum does not have a negative impact on performance and decide to merge it, then we can revert this patch as it would not be necessary anymore. But if we decide to skip the enum-as-bool approach to its performance issues, then we would have at least fixed the false non-exhaustive diagnostics for bools by means of this patch.
Swift SVN r26650
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
initializer but has no "parent" PatternBindingDecl or Pattern (i.e.
paramdecls). This is currently set on decls in the pattern of
foreach loops and case patterns, but I'll add it to other places I
find as well.
NFC since this bit is only set and not read, just more yak shaving.
Swift SVN r23910
This preserves more of source info (e.g. API name location) and simplifies things since
we don't have to construct ParamDecls for the unnamed parameters later on.
Swift SVN r17828
Do some QoI heroics here so that we get good diagnostics and Fix-Its
when we attempt to override but fail to do so because one picked
different argument names.
Swift SVN r16784
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
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
If 'case X:' occurs in enum context, 'X' may by itself refer to an enum element, and we should build a pattern from that. While we're here, clean up the grody resolution code we wrote last time to build up an IdentTypeRepr so that we reuse all the name resolution smarts from resolveIdentifierType. Fixes <rdar://problem/15194007>.
Swift SVN r9442
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
-Refactor Parser to stop creating types
-Refactor TypeChecker to create types by resolving TypeReprs.
-Remove "validation" bit from the type system.
We don't need to "validate" every type that gets created but there's still a validation bit in TypeLoc,
necessary because of generic substitutions.
Swift SVN r6326
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
