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
exposed keyword arguments into the TuplePatterns labels.
Switch tuple conversion to use tuplepattern labels instead of parameter labels.
Swift SVN r26861
- Enhance PBD with a whereExpr/elseStmt field to hold this.
- Start parsing the pattern of let/var decls as a potentially refutable pattern. It becomes
a semantic error to use a refutable pattern without an 'else' (diagnostics not in place yet).
- Change validatePatternBindingDecl to use 'defer' instead of a goto to ensure cleanups on exit.
- Have it resolve the pattern in a PBD, rewriting it from expressions into pattern nodes when valid.
- Teach resolvePattern to handle TypedPatterns now that they can appear (wrapping) refutable patterns.
- Teach resolvePattern to handle refutable patterns in PBD's without initializers by emitting a diagnostic
instead of by barfing, fixing regressions on validation tests my previous patch caused, and fixing
two existing validation test crashers.
Sema, silgen, and more tests coming later.
Swift SVN r26706
Start parsing a "trailing" where clause for extension declarations, which follows the extended type name and (optional) inheritance clause. Such a where clause is only currently permitted for protocol extensions right now.
When used on a protocol extension, it allows one to create a more-constrained protocol extension, e.g.,
extension CollectionType where Self.Generator.Element : Equatable { ... }
which appears to be working, at least in the obvious cases I've tried.
More cleanup, tests, and penance for the previous commit's "--crash" introductions still to come.
Swift SVN r26689
Rename 'assignment' attribute of infix operators to 'mutating'. Add
'has_assignment' attribute, which results in an implicit declaration of
the assignment version of the same operator. Parse "func =foo"
declaration and "foo.=bar" expression. Validate some basic properties of
in-place methods.
Not yet implemented: automatic generation of wrapper for =foo() if foo()
is implemented, or vice versa; likewise for operators.
Swift SVN r26508
is invalid and produces a ParseError, recovery by producing an AST with an ErrorExpr in it
instead of dropping the initializer on the floor. This silences downstream errors about
"must have an initializer" sorts of stuff.
Swift SVN r26405
This lets us tag imported declarations with arbitrary synthesized
protocols. Use it to handle imported raw option sets as well as the
RawRepresentable conformances of enums that come in as structs.
Swift SVN r26298
When a developer auto-completes an override function,
we collect the keywords that have already been specified
by the developer, so that the code completion strings do
not duplicate them.
rdar://16738036
Swift SVN r26230
Previously, a multi-pattern var/let decl like:
var x = 4, y = 17
would produce two pattern binding decls (one for x=4 one for y=17). This is convenient
in some ways, but is bad for source reproducibility from the ASTs (see, e.g. the improvements
in test/IDE/structure.swift and test/decl/inherit/initializer.swift).
The hardest part of this change was to get parseDeclVar to set up the AST in a way
compatible with our existing assumptions. I ended up with an approach that forms PBDs in
more erroneous cases than before. One downside of this is that we now produce a spurious
"type annotation missing in pattern"
diagnostic in some cases. I'll take care of that in a follow-on patch.
Swift SVN r26224
The deallocating parameter convention is a new convention put on a
non-trivial parameter if the caller function guarantees to the callee
that the parameter has the deallocating bit set in its object header.
This means that retains and releases do not need to be emitted on these
parameters even though they are non-trivial. This helps to solve a bug
in +0 self and makes it trivial for the optimizer to perform
optimizations based on this property.
It is not emitted yet by SILGen and will only be put on the self
argument of Deallocator functions.
Swift SVN r26179
- Strength reduce isAtStartOfBindingName() to just check for
identifier or _ and inline into its two callers.
- Rename Token::isIdentifierOrNone to isIdentifierOrUnderscore.
- Teach InVarOrLetPattern about matching patterns, so that the
parser knows when it is parsing an expression as a matching
pattern but is not yet inside a let/var pattern.
- Use newfound knowledge of matching patterns to refine handling
of unexpected let/var when parsing an expression, but not in a
pattern context, slightly improving QoI in invalid cases.
Swift SVN r26172
This is still a subject of discussion on swift-dev, but it seems like clearly the right
way to go to me. If it turns out that this isn't a good direction, I'll revert this and
subsequent patches built on top of it.
Swift SVN r26168
duplicated by the InVarOrLetPattern state in the Parser object. Beef
InVarOrLetPattern up so that we can remove it.
NFC except that we now reject pointless let patterns in foreach loops,
similar to how we reject var patterns inside of let patterns.
Swift SVN r26163
This changes 'if let' conditions to take general refutable patterns, instead of
taking a irrefutable pattern and implicitly matching against an optional.
Where before you might have written:
if let x = foo() {
you now need to write:
if let x? = foo() {
The upshot of this is that you can write anything in an 'if let' that you can
write in a 'case let' in a switch statement, which is pretty general.
To aid with migration, this special cases certain really common patterns like
the above (and any other irrefutable cases, like "if let (a,b) = foo()", and
tells you where to insert the ?. It also special cases type annotations like
"if let x : AnyObject = " since they are no longer allowed.
For transitional purposes, I have intentionally downgraded the most common
diagnostic into a warning instead of an error. This means that you'll get:
t.swift:26:10: warning: condition requires a refutable pattern match; did you mean to match an optional?
if let a = f() {
^
?
I think this is important to stage in, because this is a pretty significant
source breaking change and not everyone internally may want to deal with it
at the same time. I filed 20166013 to remember to upgrade this to an error.
In addition to being a nice user feature, this is a nice cleanup of the guts
of the compiler, since it eliminates the "isConditional()" bit from
PatternBindingDecl, along with the special case logic in the compiler to handle
it (which variously added and removed Optional around these things).
Swift SVN r26150
conjunction with .fixItInsert(). As such, introduce a helper named
.fixItInsertAfter() that does what we all want. Adopt this in various
places around the compiler. NFC.
Swift SVN r26147
Make this diagnostic a little nicer in other ways, too:
- Highlight the whole attribute (including the at-sign).
- Don't hardcode the string "objc".
Swift SVN r25999
Corrected several places where compiler generated AST nodes were not properly
marked as implicit.
For interpolated strings also fixed string segment locations and made sure
the first and last segments are preserved in AST even if they are empty.
Swift SVN r25983
auto-completing @attributes. By delaying the handling of code completion token after the entire decl being parsed, we know
what are the targets of the attribute to finishe, thus, only suggesting those applicable attributes.
Swift SVN r25938
context-sensitive. The first step is to recommend parameter-applicable
attributes only when the code completion token is found inside a
param decl.
Swift SVN r25810
step to achieve this goal, this change allows the first parameter of
@availability to be completed with either one of the following four
platforms: *, iOS, iOSApplicationExtension, and OSX.
rdar://19541135
Swift SVN r25703
Otherwise we'll get all the way to IRGen and then try to emit them. And try
to reference them in serialization.
rdar://problem/19935034
Swift SVN r25567
Before we would produce (with no fixit):
a.swift:1:13: error: attribute can only be applied to declarations, not types
let step : @autoclosure() -> ()
^
now we produce (with a fixit):
a.swift:1:13: error: 'autoclosure' attribute is now an attribute of the parameter declaration, not its type
let step : @autoclosure() -> ()
~^~~~~~~~~~~
@autoclosure
This also generates the same handles other declattributes incorrectly applied to types.
Swift SVN r24946
Since ParserResult<T> required to have an AST node if there is no error and Parser::parseLineDirective()
does not return any node after successful parsing, we should not try to construct DeclResult.
Swift SVN r24755
Local type declarations are saved in the source file during parsing,
now serialized as decls. Some of these may be defined in DeclContexts
which aren't Decls and previously weren't serialized. Create four new
record kinds:
* PatternBindingInitializer
* DefaultArgumentInitializer
* AbstractClosureExpr
* TopLevelCodeDecl
These new records are used to only preserve enough information for
remangling in the debugger, and parental context relationships.
Finally, provide a lookup API in the module to search by mangled name.
With the new remangling API, the debugging lifecycle for local types
should be complete.
The extra LOCAL_CONTEXT record will compressed back down in a
subsequent patch.
Swift SVN r24739
Attributes @__objc_bridged, @__raw_doc_comment and @__accessibility are not supposed to be
coming from input file and actually crash parseNewDeclAttribute(…) when they are.
Swift SVN r24697
