We were miscalculating 'isRightBound' when the RHS was a code-completion
token leading to missing completions in unspaced binary expressions
1+<here>
1...<here>
rdar://problem/24278699
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 {}
^~
,
When one spells a compound declaration name in the source (e.g.,
insertSubview(_:aboveSubview:), keep track of the locations of the
base name, parentheses, and argument labels.
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
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 {
^
Also cleaned up unnecessary body.isNonNull() check here. The code just
above already constructs a synthetic empty brace stmt for the body if
it didn’t have a real one.
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.
Parameters (to methods, initializers, accessors, subscripts, etc) have always been represented
as Pattern's (of a particular sort), stemming from an early design direction that was abandoned.
Being built on top of patterns leads to patterns being overly complicated (e.g. tuple patterns
have to have varargs and default parameters) and make working on parameter lists complicated
and error prone. This might have been ok in 2015, but there is no way we can live like this in
2016.
Instead of using Patterns, carve out a new ParameterList and Parameter type to represent all the
parameter specific stuff. This simplifies many things and allows a lot of simplifications.
Unfortunately, I wasn't able to do this very incrementally, so this is a huge patch. The good
news is that it erases a ton of code, and the technical debt that went with it. Ignoring test
suite changes, we have:
77 files changed, 2359 insertions(+), 3221 deletions(-)
This patch also makes a bunch of wierd things dead, but I'll sweep those out in follow-on
patches.
Fixes <rdar://problem/22846558> No code completions in Foo( when Foo has error type
Fixes <rdar://problem/24026538> Slight regression in generated header, which I filed to go with 3a23d75.
Fixes an overloading bug involving default arguments and curried functions (see the diff to
Constraints/diagnostics.swift, which we now correctly accept).
Fixes cases where problems with parameters would get emitted multiple times, e.g. in the
test/Parse/subscripting.swift testcase.
The source range for ParamDecl now includes its type, which permutes some of the IDE / SourceModel tests
(for the better, I think).
Eliminates the bogus "type annotation missing in pattern" error message when a type isn't
specified for a parameter (see test/decl/func/functions.swift).
This now consistently parenthesizes argument lists in function types, which leads to many diffs in the
SILGen tests among others.
This does break the "sibling indentation" test in SourceKit/CodeFormat/indent-sibling.swift, and
I haven't been able to figure it out. Given that this is experimental functionality anyway,
I'm just XFAILing the test for now. i'll look at it separately from this mongo diff.
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 illegal:
switch thing {
case .A(var x):
modify(x0
}
And provide a replacement 'var' -> 'let' fix-it.
rdar://problem/23172698
Swift SVN r32883
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
This is a WIP to make CompilerVersion more general.
- Rename CompilerVersion to just "Version"
- Make version comparison general and put _compiler_version special logic
with its second version component in a specialized parsing function
- Add a generic version parsing function
Swift SVN r32726
If an unknown architecture or operating system argument is provided
to the arch/os build configuration functions, put the warning caret
on the actual argument instead of at the build config names.
rdar://problem/22052176
Swift SVN r32223
'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
A couple of small tweaks to _compiler_version based on review comments:
- Fix &&/|| rejection to work with _compiler_version on either side of the
expression. Also add some test cases around this.
- Use clang/LLVM facilities for isdigit and atoi.
- Assert if parsing an invalid version string and there is no diagnostic
engine.
- Clean up some crumbs in the CMake configs.
rdar://problem/22730282
Swift SVN r32212
When completing at the sequence position of for each statment (for i in <HRER> {}),
values of sequence type should have higher priority than the rest.
Swift SVN r32202
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
When users invoke code completion at an argument position, we suggest argument names,
if required however not specified, or a list of argument values. These values are annotated
with their type relation to the expected argument types, so that
Xcode can prioritize those values that apply over those that do not.
This also fixes: rdar://21727063
Swift SVN r31505
The defer body func is only ever fully applied, so SILGen can avoid allocating a closure for it if it's declared as a 'func', making it slightly more efficient at -Onone.
Swift SVN r30638
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
These variables really are local variables -- they have have a
TopLevelCodeDecl as their DeclContext rather than the SourceFile.
Treating them as global variables caused crashes in serialization.
We need an overhaul of top-level variables in script files anyway
(see rdar://problem/20992489&21628526), but this fixes the immediate
issue.
rdar://problem/21928533
Swift SVN r30519
We always expect to get a pattern, but in top-level completion we forgot
to build the fallback AnyPattern to go in the error result.
rdar://21661308
Swift SVN r30078
