The tentantive parse is used for diagnostic purposes but can cause code-completion to delay the same decl twice.
The range of CodeCompletionExpr was previously character range which invalidated invariants of the AST.
Fixes:
validation-test/IDE/crashers_fixed/084-swift-parser-consumedecl.swift
validation-test/IDE/crashers_fixed/104-swift-gettypeofcompletioncontextexpr.swift
Fixes: https://bugs.swift.org/browse/SR-3208
When '@' or 'inout' found in expression context, try to parse it as a type.
So that we can resolve '[(inout Int) -> Void]' as a TypeExpr expression
for ArraySliceType.
These APIs return SourceLocs, and eventually the Parser should consume
tokens, which now include source trivia such as whitespace and comments,
and package them into a purely syntactic tree. Just a tiny step. NFC.
Store leading a trailing "trivia" around a token, such as whitespace,
comments, doc comments, and escaping backticks. These are syntactically
important for preserving formatting when printing ASTs but don't
semantically affect the program.
Tokens take all trailing trivia up to, but not including, the next
newline. This is important to maintain checks that statements without
semicolon separators start on a new line, among other things.
Trivia are now data attached to the ends of tokens, not tokens
themselves.
Create a new Syntax sublibrary for upcoming immutable, persistent,
thread-safe ASTs, which will contain only the syntactic information
about source structure, as well as for generating new source code, and
structural editing. Proactively move swift::Token into there.
Since this patch is getting a bit large, a token fuzzer which checks
for round-trip equivlence with the workflow:
fuzzer => token stream => file1
=> Lexer => token stream => file 2 => diff(file1, file2)
Will arrive in a subsequent commit.
This patch does not change the grammar.
We are expecting a new identifier, and completing global names is not
helpful. If the editor chooses to automatically provide completions, it
may be actively harmful if we end up inserting a completion here.
rdar://problem/29118428
`@foo=bar` style attributes are no longer supported anyway.
So as ',' separated attribute list.
In `canParseTypeTupleBody()`, `canParseType()` can more accurately consume
type attributes.
In `isStartOfGetSetAccessor`, we can trivially inline the functionality.
* [Parse] Remove unused GreaterThanIsOperatorRAII. NFC
Last usage was removed in 68af974227.
* [Parse] Remove unused ArgumentIsParameter flag. NFC
Last usage was removed in 4e4173f2e6
Rather than parsing the call arguments (or similar, e.g., subscript)
as a parenthesized expression or tuple, then later reworking that
ParenExpr/TupleExpr if a trailing closure comes along, then digging
through that ParenExpr/TupleExpr to pull out the arguments and
trailing closure... just parse the expression list and trailing
closure together, then directly form the appropriate AST node with
arguments/labels/label locations/trailing closure.
Fixes rdar://problem/19804707, which is an issue where trailing
closures weren't working with unresolved member expressions (e.g.,
".foo {... }"), and is a stepping-stone to SE-0111.
Factor out the trailing storage of call arguments, since we'll need it
for a few different kinds of expression nodes. Use it for both
CallExpr (which already had this storage, albeit with a specialized
implementation) and now SubscriptExpr.
Yet another step on the way to SE-0111, capture the argument labels
(and their locations) directly in CallExpr, rather than depending on
them being part of the tuple argument.
Introduce several new factory methods to create CallExprs, and hide
the constructor. The primary reason for this refactor is to start
moving clients over to the factory method that takes the call
arguments separately from the argument labels. Internally, it
repackages those arguments into a TupleExpr or ParenExpr (as
appropriate) so the result ASTs are the same. However, this will make
it easier for us to tease out the arguments themselves in the
implementation of SE-0111.
- Any is made into a keyword which is always resolved into a TypeExpr,
allowing the removal of the type system code to find TheAnyType before
an unconstrained lookup.
- Types called `Any` can be declared, they are looked up as any other
identifier is
- Renaming/redefining behaviour of source loc methods on
ProtocolCompositionTypeRepr. Added a createEmptyComposition static
method too.
- Code highlighting treats Any as a type
- simplifyTypeExpr also does not rely on source to get operator name.
- Any is now handled properly in canParseType() which was causing
generic param lists containing ‘Any’ to fail
- The import objc id as Any work has been relying on getting a decl for
the Any type. I fix up the clang importer to use Context.TheAnyType
(instead of getAnyDecl()->getDeclaredType()). When importing the id
typedef, we create a typealias to Any and declare it unavaliable.
This commit defines the ‘Any’ keyword, implements parsing for composing
types with an infix ‘&’, and provides a fixit to convert ‘protocol<>’
- Updated tests & stdlib for new composition syntax
- Provide errors when compositions used in inheritance.
Any is treated as a contextual keyword. The name ‘Any’
is used emit the empty composition type. We have to
stop user declaring top level types spelled ‘Any’ too.
Fix-it suggests normal argument expression, instead of of enclosing whole
expression with parens.
* Moved diagnostic logic to Sema, because we have to add correct argument
label for the closure.
if arr.starts(with: IDs) { $0.id == $2 } { ... }
~~^
, isEquivalent: )
* We now accept trailing closures for each expressions and right before `where`
clause, as well as closures right before the body.
if let _ = maybeInt { 1 }, someOtherCondition { ... }
~^
( )
for let x in arr.map { $0 * 4 } where x != 0 { ... }
~^
( )
silently, have the lexer return it as an unknown token. Enhance the expr parser to
detect these things and squash any expression in progress into an ErrorExpr. This
allows us to silence really bad downstream errors. For example, on:
struct S { func f() {} }
func f() {
_ = S.
}
we formerly produced:
x.swift:5:8: error: expected member name following '.'
x.swift:5:7: error: expected member name or constructor call after type name
x.swift:5:7: note: add arguments after the type to construct a value of the type
x.swift:5:7: note: use '.self' to reference the type object
we now emit just the first one. This fixes:
<rdar://problem/22290244> QoI: "UIColor." gives two issues, should only give one
Implement code completion support for Objective-C #keyPath
expressions, using semantic analysis of the partially-typed keypath
argument to provide an appropriate set of results (i.e., just
properties and types).
This implements all of the necessary parts of SE-0062 / SR-1237 /
rdar://problem/25710611, although at some point I'd like to follow it
up with some warnings to help migrate existing string literals to
Implement the Objective-C #keyPath expression, which maps a sequence
of @objc property accesses to a key-path suitable for use with
Cocoa[Touch]. The implementation handles @objc properties of types
that are either @objc or can be bridged to Objective-C, including the
collections that work with key-value coding (Array/NSArray,
Dictionary/NSDictionary, Set/NSSet).
Still to come: code completion support and Fix-Its to migrate string
literal keypaths to #keyPath.
Implements the bulk of SR-1237 / rdar://problem/25710611.
Implement basic code completion support for #selector with property
getters/setters. The vast majority of this implementation comes from
Alex Hoppen (@ahoppen), with only a handful of my own tweaks. Alex has
more interesting ideas on improving this that I wasn't quite ready to
commit to, so this is more basic than the overall goal.
Implements the core functionality of SE-0064 / SR-1239, which
introduces support for accessing the Objective-C selectors of the
getter and setter of an @objc property via #selector(getter:
propertyName) and #selector(setter: propertyName).
Introduce a bunch of QoI around mistakes using #selector to refer to a
property without the "getter:" or "setter:", using Fix-Its to help the
user get it right. There is more to do in this area, still, but we
have an end-to-end feature working.
Much of the implementation and nearly all of the test cases are from
Alex Hoppen (@ahoppen). I've done a bit of refactoring, simplified the
AST representation, and replaced Alex's custom
expression-to-declaration logic with an extension to the constraint
solver. The last bit might be short-lived, based on swift-evolution
PR280, which narrows the syntax of #selector considerably.
* Implement the majority of parsing support for SE-0039.
* Parse old object literals names using new syntax and provide FixIt.
For example, parse "#Image(imageLiteral:...)" and provide a FixIt to
change it to "#imageLiteral(resourceName:...)". Now we see something like:
test.swift:4:9: error: '#Image' has been renamed to '#imageLiteral
var y = #Image(imageLiteral: "image.jpg")
^~~~~~ ~~~~~~~~~~~~
#imageLiteral resourceName
Handling the old syntax, and providing a FixIt for that, will be handled in a separate
commit.
Needs tests. Will be provided in later commit once full parsing support is done.
* Add back pieces of syntax map for object literals.
* Add parsing support for old object literal syntax.
... and provide fixits to new syntax.
Full tests to come in later commit.
* Improve parsing of invalid object literals with old syntax.
* Do not include bracket in code completion results.
* Remove defunct code in SyntaxModel.
* Add tests for migration fixits.
* Add literals to code completion overload tests.
@akyrtzi told me this should be fine.
* Clean up response tests not to include full paths.
* Further adjust offsets.
* Mark initializer for _ColorLiteralConvertible in UIKit as @nonobjc.
* Put attribute in the correct place.
Previously it was not possible to parse expressions of the form
[Int -> Int]()
because no Expr could represent the '->' token and be converted later
into a FunctionTypeRepr. This commit introduces ArrowExpr which exists
solely to be converted to FunctionTypeRepr later by simplifyTypeExpr.
https://bugs.swift.org/browse/SR-502
This fixit checks if a decl with the identical name can be found in the parent type
context; if can, we add "self." to try to resolve the issue. rdar://25389852
It is a common problem that people use a call to a function with a
trailing closure in a if condition, foreach loop, etc. These don't allow
trailing closures, because they are ambiguous with the brace-enclosed body
of the conditional statement.
In an effort to improve QoI on this, perform lookahead to disambiguate the most common
form of this, in a very narrow situation. This allows us to produce a nice error
with fixit hints like:
t.swift:26:25: error: trailing closure requires parentheses for disambiguation in this context
for _ in numbers.filter {$0 > 4} {
^
instead of spewing out this garbage:
t.swift:26:26: error: anonymous closure argument not contained in a closure
for _ in numbers.filter {$0 > 4} {
^
t.swift:26:33: error: consecutive statements on a line must be separated by ';'
for _ in numbers.filter {$0 > 4} {
^
;
t.swift:26:34: error: statement cannot begin with a closure expression
for _ in numbers.filter {$0 > 4} {
^
t.swift:26:34: note: explicitly discard the result of the closure by assigning to '_'
for _ in numbers.filter {$0 > 4} {
^
_ =
t.swift:26:34: error: braced block of statements is an unused closure
for _ in numbers.filter {$0 > 4} {
^
t.swift:26:18: error: type '(@noescape (Int) throws -> Bool) throws -> [Int]' does not conform to protocol 'Sequence'
for _ in numbers.filter {$0 > 4} {
^
t.swift:26:34: error: expression resolves to an unused function
for _ in numbers.filter {$0 > 4} {
^
