1. Array type parsing for postfix array types Int[]. We now handle this
in the parser, but remove the AST representation of this old form. We
also stop making vague promises about the future by saying that "fixed
size arrays aren't supported... yet". Removal of this fixes a compiler
crasher too.
2. Remove the special case support for migrating @autoclosure from types
to parameters, which was Swift 1.0/1.1 syntax. The world has moved or
we don't care anymore.
3. Remove upgrade support for # arguments (nee "backtick" arguments), which
was a Swift 1.x'ism abolished in an effort to simplify method naming
rules.
NFC on valid code.
Revert "Make function parameters and refutable patterns always
immutable"
This reverts commit 8f2fbdc93a.
Once we have finally merged master into the Swift 2.2 branch to be, we
should revert this commit to turn the errors back on for Swift 3.0.
All refutable patterns and function parameters marked with 'var'
is now an error.
- Using explicit 'let' keyword on function parameters causes a warning.
- Don't suggest making function parameters mutable
- Remove uses in the standard library
- Update tests
rdar://problem/23378003
Make the following illegal:
switch thing {
case .A(var x):
modify(x0
}
And provide a replacement 'var' -> 'let' fix-it.
rdar://problem/23172698
Swift SVN r32883
There's still work left to do. In terms of next steps, there's still rdar://problem/22126141, which covers removing the 'workaround' overloads for print (that prevent bogus overload resolution failures), as well as providing a decent diagnostic when users invoke print with 'appendNewline'.
Swift SVN r30976
- Have DiagnosticEngine produce "aka" annotations for sugared types.
- Fix the "optional type '@lvalue C?' cannot be used as a boolean; test for '!= nil' instead"
diagnostic to stop printing @lvalue noise.
This addresses:
<rdar://problem/19036351> QoI: Print minimally-desugared 'aka' types like Clang does
Swift SVN r30587
We do this by banning single-element tuple patterns with a label (in most cases).
We now produce:
x.swift:2:8: error: label is not allowed on single element tuple pattern
let (responseObject: Int?) = f()
^
x.swift:2:7: note: remove the parentheses to make this a type annotation
let (responseObject: Int?) = f()
^ ~
x.swift:2:8: note: remove the label to make this a tuple pattern
let (responseObject: Int?) = f()
^~~~~~~~~~~~~~~
Swift SVN r26898
early instead of leaving them to TypeCheckExpr to find in an arbitrary "late"
place in type checking. This gives us better (more localized) diagnostics and
reduces downstream errors when a pattern is malformed. This is the
foundation to produce more specific errors than "invalid pattern"
Swift SVN r26802
- 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
In an existential context, allow 'case Enum.Case:' by implicitly introducing a cast pattern, treating it as 'case Enum.Case as Enum:'. This will be important for the error handling design, where we want ErrorType-conforming enums to be pattern-matchable out of an ErrorType existential using 'catch' patterns.
Swift SVN r25968
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
In a situation like::
enum Foo {
case Bar(bar: Int)
}
switch foo {
case let .Bar(bar):
use(bar)
}
It's extremely unlikely anyone expects 'bar' to have type '(bar: Int)' rather than 'Int', especially because we try to eliminate single-element tuple types pretty much everywhere else. Put in a hack so that, when we see a paren pattern as the payload subpattern of an enum case pattern, and the payload has a single-element tuple type, we transform the paren pattern into a tuple pattern, which semantically matches off the label. Fixes rdar://problem/18923473, and a lot of dupes.
Swift SVN r25541
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
modifiers and with the func implementations of the operators. This resolves the rest of:
<rdar://problem/17527000> change operator declarations from "operator prefix" to "prefix operator" & make operator a keyword
Swift SVN r19931
eliminating the @'s from them when used on func's. This is progress towards
<rdar://problem/17527000> change operator declarations from "operator prefix" to "prefix operator" & make operator a keyword
This also consolidates rejection of custom operator definitions into one
place and makes it consistent, and adds postfix "?" to the list of rejected
operators.
This also changes the demangler to demangle weak/inout/postfix and related things
without the @.
Swift SVN r19929
When checking an isa pattern that requires either collection
downcasting or bridging through an Objective-C class (e.g.,
"is String" or "is Dictionary<String, Int>"), form a conditional
downcast and place it in an expression pattern.
With this change, we can test for these cases (with "is") but we can't
capture the value produced on success (e.g., for "let str as
String"). This is a first small step toward <rdar://problem/17408934>.
Swift SVN r19070
Parse 'var', '_', and 'is' pattern forms at the top level of a matching pattern context. Keep track of VarPatternDepth in the parser state and raise an error if 'var' appears in a 'var'.
Swift SVN r5839
