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
If the returned expression has the same indentation as the "return"
keyword, warn. This warning already existed but wasn't happening
for single-expression closures. Move emission of the warning from Sema
to Parse.
<rdar://problem/16798323>
Make the following patterns illegal:
if var x = ... {
...
}
guard var x = ... else {
...
}
while var x = ... {
...
}
And provide a replacement fixit 'var' -> 'let'.
rdar://problem/23172698
Swift SVN r32855
Don't allow a pattern like:
for var x in sequence {
...
}
and provide a removal fix-it for the 'var' keyword.
Additionally, for the following code:
for let x in sequence {
...
}
Provide a removal fix-it since the 'let' specifier is now
redundant.
rdar://problem/23172698
Swift SVN r32818
Internal compiler versions must be able to be packed into a 64-bit
value, and there is a limit on how many components we can use and which
values they can take on.
Versions must have no more than five components, assuming a version
X.Y.Z.a.b, where X, Y, Z, a, and b are integers with the following
inclusive ranges:
X: [0 - 214747]
Y: [0 - 999]
Z: [0 - 999]
a: [0 - 999]
b: [0 - 999]
Swift SVN r32724
To better indicate that the second _compiler_version component isn't
used in the ordering, warn and provide a fix-it replacement if it's
not a '*' in source code.
To make the diagnostics a little easier to emit, I cleaned up the
parsing code to use StringRef::split instead of a hand-written
tokenizer.
rdar://problem/23080845
Swift SVN r32673
'arch' and 'os' build configurations with valid identifiers as
arguments, but which are unknown to the compiler, will cause the
compiler to silently skip over that code as it has an inactive clause.
Emit a diagnostic, but not an error so as not to inadvertantly break
code that may be in a compiler without knowledge of a particular
operating system or architecture.
rdar://problem/22052176
Swift SVN r32219
This configuration clause will suppress lex diagnostics and skip parsing
altogether if the code under the clause isn't active - the compiler must
have a repository version greater than or equal to the version given to
_compiler_version.
This option is only meant to be used sparingly and not to track the
Swift *language* version.
Example, if using a compiler versioned 700.0.28:
#if _compiler_version("700.0.23")
print("This code will compile for versions 700.0.23 and later.")
#else
This + code + will + not + be + parsed
#endif
Included are new diagnostics for checking that the version is formatted
correctly and isn't empty.
New tests:
- Compiler version comparison unit tests
- Build configuration diagnostics
- Skipping parsing of code under inactive clauses
rdar://problem/22730282
Swift SVN r32195
Emit a fix-it replacing them with double-quote string literals.
<rdar://problem/21950709> QoI: Parse single-quoted literals like double-quoted literals
Swift SVN r31973
Allow untyped placeholder to take arbitrary type, but default to Void.
Add _undefined<T>() function, which is like fatalError() but has
arbitrary return type. In playground mode, merely warn about outstanding
placeholders instead of erroring out, and transform placeholders into
calls to _undefined(). This way, code with outstanding placeholders will
only crash when it attempts to evaluate such placeholders.
<rdar://problem/21167372> transform EditorPlaceholderExpr into fatalError()
Swift SVN r31481
Teach skipToEndOfInterpolatedExpression() to match quote marks as well
as parentheses in the interpolated expression. This makes expressions
like "hello \(names["bob"])" possible.
Swift SVN r31283
Requiring a variadic parameter to come at the end of the parameter
list is an old restriction that makes no sense nowadays, and which we
had all thought we had already lifted. It made variadic parameters
unusable with trailing closures or defaulted arguments, and made our
new print() design unimplementable.
Remove this restriction, replacing it with a less onerous and slightly
less silly restriction that we not have more than one variadic
parameter in a given parameter clause. Fixes rdar://problem/20127197.
Swift SVN r30542
Now, instead of writing, e.g.,
func f(Int) { ... }
one must write the more-generally-consistent and explicit
func f(_: Int) { ... }
Fixes rdar://problem/16737312.
Swift SVN r29609
If 'x.init' appears as a member reference other than 'self.init' or 'super.init' within an initializer, treat it as a regular static member lookup for 'init' members. This allows a more explicit syntax for dynamic initializations; 'self.someMetatype()' looks too much like it's invoking a method. It also allows for partial applications of initializers using 'someMetatype.init' (though this needs some SILGen fixes, coming up next). While we're in the neighborhood, do some other correctness and QoI fixes:
- Only lookup initializers as members of metatypes, not instances, and add a fixit (instead of crashing) to insert '.dynamicType' if the initializer is found on an instance.
- Make it so that constructing a class-constrained archetype type correctly requires a 'required' or protocol initializer.
- Warn on unused initializer results. This seems to me like just the right thing to do, but is also a small guard against the fact that 'self.init' is now valid in a static method, but produces a newly-constructed value instead of delegating initialization (and evaluating to void).
Swift SVN r29344
Instead of forcing full application of '{super,self}.init' in the parser, and installing the RebindSelf semantic expr node early, make these constraints to Sema-time checks, and parse '<expr>.init' as a regular postfix production. This is a better separation of concerns, and also opens the door to supporting 'metatype.init()' in more general expression contexts (though that part still needs some follow-up sema work).
Swift SVN r29343
And for "try return", "try throw", and "try let", get even more specific,
with a fix-it to suggest moving the "try" onto the expression.
rdar://problem/21043120
Swift SVN r28862
Before:
t.swift:2:9: error: expected initial value after '='
let x = @"foo"
^
t.swift:2:8: error: consecutive statements on a line must be separated by ';'
let x = @"foo"
^
;
t.swift:2:10: error: expected an attribute name
let x = @"foo"
^
t.swift:2:10: error: expected declaration
let x = @"foo"
^
now:
t.swift:2:9: error: string literals in Swift are not preceeded by an '@' sign
let x = @"foo"
^
Swift SVN r28698
In anticipation of adding short-form @available() annotations, move validation
of #available() platform/version lists out of Sema and into the parser. This
also enables slightly more graceful recovery from errors.
Swift SVN r28637
instead of being an expression.
To the user, this has a couple of behavior changes, stemming from its non-expression-likeness.
- #available cannot be parenthesized anymore
- #available is in its own clause, not used in a 'where' clause of if/let.
Also, the implementation in the compiler is simpler and fits the model better. This
fixes:
<rdar://problem/20904820> Following a "let" condition with #available is incorrectly rejected
Swift SVN r28521
