This tweet: https://twitter.com/radexp/status/694561060230184960 pointed out
the sad truth that most people don't know that stmt-condition can contain
(including a fixit) when they try to use && instead of commas between clauses.
Before:
t.swift:4:16: error: #available may only be used as condition of an 'if', 'guard' or 'while' statement
if x == y && #available(iOS 9, *) { }
^
t.swift:5:27: error: expected '{' after 'if' condition
if #available(iOS 9, *) && x == y {}
^
t.swift:5:37: error: braced block of statements is an unused closure
if #available(iOS 9, *) && x == y {}
^
t.swift:5:37: error: expression resolves to an unused function
if #available(iOS 9, *) && x == y {}
^~
After:
t.swift:4:13: error: expected ',' joining parts of a multi-clause condition
if x == y && #available(iOS 9, *) { }
^~
,
t.swift:5:27: error: expected ',' joining parts of a multi-clause condition
if #available(iOS 9, *) && x == y {}
^~
,
Fix <rdar://problem/16812341> QoI: Poor error message when providing a default value for a subscript parameter
by emitting a more specific diagnostic about the cases that aren't allowed.
Introduce a new "swift" build configuration that guards declarations
and statements with a language version - if the current language version
of the compiler is at least that version, the block will parse as normal.
For inactive blocks, the code will not be parsed an no diagnostics will
be emitted there.
Example:
#if swift(>=2.2)
print("Active")
#else
this code will not parse or emit diagnostics
#endif
https://github.com/apple/swift-evolution/blob/master/proposals/0020-if-swift-version.md
rdar://problem/19823607
As there are no instructions left which produce multiple result values, this is a NFC regarding the generated SIL and generated code.
Although this commit is large, most changes are straightforward adoptions to the changes in the ValueBase and SILValue classes.
Basic implementatation of SE-0021, naming functions with argument
labels. Handle parsing of compound function names in various
unqualified-identifier productions, updating the AST representation of
various expressions from Identifiers to DeclNames. The result doesn't
capture all of the source locations we want; more on that later.
As part of this, remove the parsing code for the "selector-style"
method names, since we now have a replacement. The feature was never
publicized and doesn't make sense in Swift, so zap it outright.
People will keep typing try/catch either due to muscle memory from other languages or
when they are first learning swift. We now produce a nice error message + fixit of:
t.swift:14:3: error: the 'do' keyword is used to specify a 'catch' region
try {
^~~
do
instead of spewing out:
t.swift:15:4: error: consecutive statements on a line must be separated by ';'
} catch { }
^
;
t.swift:15:5: error: expected expression
} catch { }
^
t.swift:15:11: error: braced block of statements is an unused closure
} catch { }
^
t.swift:14:7: error: expression resolves to an unused function
try {
~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
t.swift:15:11: error: expression resolves to an unused function
} catch { }
^~~
t.swift:14:3: warning: no calls to throwing functions occur within 'try' expression
try {
^
Diagnostic categories are entirely unused and arguably useless as
implemented, as they merely denote the sub-component of the
compiler.
As far as categorizing warnings are concerned, I'm abandoning the
effort for now, as the utility is marginal and Swift and the Swift
compiler are probalby not ready for these to be nailed down. For the
sake of cleanliness, the CATEGORY field is also stripped from
WARNINGS.
If there's a need for automatic identifying of compiler sub-components
for diagnstics in the future, there are better ways to do this.
NFC
Adds an associatedtype keyword to the parser tokens, and accepts either
typealias or associatedtype to create an AssociatedTypeDecl, warning
that the former is deprecated. The ASTPrinter now emits associatedtype
for AssociatedTypeDecls.
Separated AssociatedType from TypeAlias as two different kinds of
CodeCompletionDeclKinds. This part probably doesn’t turn out to be
absolutely necessary currently, but it is nice cleanup from formerly
specifically glomming the two together.
And then many, many changes to tests. The actual new tests for the fixits
is at the end of Generics/associated_types.swift.
Introduce a new attribute, swift3_migration, that lets us describe the
transformation required to map a Swift 2.x API into its Swift 3
equivalent. The only transformation understood now is "renamed" (to
some other declaration name), but there's a message field where we can
record information about other changes. The attribute can grow
somewhat (e.g., to represent parameter reordering) as we need it.
Right now, we do nothing but store and validate this attribute.
This adds some heuristics so we can emit a fixit to remove extraneous
whitespace after a . and diagnose the case where a member just hasn't
been written yet better. This also improves handling of tok::unknown
throughout the parser a bit.
This is a re-commit of ff4ea54 with an update for a SourceKit test.
This adds some heuristics so we can emit a fixit to remove extraneous
whitespace after a . and diagnose the case where a member just hasn't
been written yet better. This also improves handling of tok::unknown
throughout the parser a bit.
accept closure arguments with API names (but only in a parenthesized parameter list).
While it could theoretically be interesting to support API names on closures, this
is never something we intended to support, and a lot of implementation work would be
necessary to make them correct. Just correctly reject them even if parenthesized.
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.
We should also eliminate the isOldSyntax as well, and just do the
error recovery in the parser (there is no need to retain the sugar here
anymore), but I'll do that as a separate change since it could be behavior
changing.
we used to say:
error: expected '{' for subscripting
we now say:
error: subscript in protocol must have explicit { get } or { get set } specifier
and produce a fixit to insert { get set }
Allow all keywords except for parameter introducers (var/let/inout) to
be argument labels when declaring or calling a
function/initializer/subscript, e.g., this
func touchesMatching(phase: NSTouchPhase, `in` view: NSView?) -> Set<NSTouch>
can now be expressed as
func touchesMatching(phase: NSTouchPhase, in view: NSView?) -> Set<NSTouch>
and the call goes from
event.touchesMatching(phase, `in`: view)
to
event.touchesMatching(phase, in: view)
Fixes [SR-344](https://bugs.swift.org/browse/SR-344) /
rdar://problem/22415674.
This patch improves error recovery for malformed operator declarations,
previously we'd stop parsing the operator decl and try to parse the
body as an expression, hilarity (and a pile of horrible errors) would
ensue.
Debug variable info may be attached to debug_value, debug_value_addr,
alloc_box, and alloc_stack instructions.
In order to write textual SIL -> SIL testcases that exercise the handling
of debug information by SIL passes, we need to make a couple of additions
to the textual SIL language. In memory, the debug information attached to
SIL instructions references information from the AST. If we want to create
debug info from parsing a textual .sil file, these bits need to be made
explicit.
Performance Notes: This is memory neutral for compilations from Swift
source code, because the variable name is still stored in the AST. For
compilations from textual source the variable name is stored in tail-
allocated memory following the SIL instruction that introduces the
variable.
<rdar://problem/22707128>
