These are used from within constraint system code, and for those uses we
need to be reading from the constraint system type map.
Add the parallel constraint system interfaces that call into the
Expr interfaces with the appropriate accessors.
withoutActuallyEscaping has a signature like `<T..., U, V, W> (@nonescaping (T...) throws<U> -> V, (@escaping (T...) throws<U> -> V) -> W) -> W, but our type system for functions unfortunately isn't quite that expressive yet, so we need to special-case it. Set up the necessary type system when resolving an overload set to reference withoutActuallyEscaping, and if a type check succeeds, build a MakeTemporarilyEscapableExpr to represent it in the type-checked AST.
Changes:
* Terminate all namespaces with the correct closing comment.
* Make sure argument names in comments match the corresponding parameter name.
* Remove redundant get() calls on smart pointers.
* Prefer using "override" or "final" instead of "virtual". Remove "virtual" where appropriate.
This parameter implements getType() for the given expression, making
it possible to use this from within the constraint system, which now
has it's own side map for types of expressions.
In most places where we were checking "is<ErrorType>()", we now mean
"any error occurred". The few exceptions are in associated type
inference, code completion, and expression diagnostics, where we might
still work with partial errors.
This fixes a usability regression with the removal of @noreturn
in Swift 3. Previously, it was legal to write this:
let callback: () -> Int = { fatalError() }
Now that the special @noreturn attribute has been replaced with
a Never type, the above fails to typecheck, because the expression
now has type 'Never', and we expect a value of type 'Int'.
Getting around this behavior requires ugly workarounds to force the
parser to treat the body as a statement rather than an expression;
for example,
let callback: () -> Int = { _ = (); fatalError() }
This patch generalized single-expression closures to allow
the 'Never to T' conversion. Note that this is rather narrow
in scope -- it only applies to closure *literals*, single-expression
ones at that, not arbitrary function *values*.
In fact, it is not really a conversion at all, but more of a
desugaring rule for single-expression closures. They can now be
summarized as follows:
- If the closure literal has contextual return type T and
the expression has Never type, the closure desugars as
{ _ = <expr> }, with no ReturnStmt.
- If the closure literal has contextual return type T for some
non-void type T, the closure desugars as { return <expr> };
the expression type must be convertible to T.
- If the closure literal has contextual return type Void, and
the expression has some non-Void type T, the closure
desugars as { _ = <expr>; return () }.
Fixes <rdar://problem/28269358> and <https://bugs.swift.org/browse/SR-2661>.
When referencing a function in the type checker, drop argument labels
when we don't need them to type-check an immediate call to that
function. This provides the semantic behavior of SE-0111, e.g.,
references to functions as values produce unlabeled function types,
without the representational change of actually dropping argument
labels from the type system.
At the moment, this only works for bare references to functions. It
still needs to be pushed through more of the type checker and more AST
nodes to work in the general case.
Keep this work behind the frontend flag
-suppress-argument-labels-in-types for now.
String literal expressions, as well as the magic literals #file and
tuple value that is then fed into one or two call expressions. For
string literals, that tuple value was implicitly splatted, breaking
AST invariants.
Instead, keep string literals and these magic literals that produce a
string as a single expression node, but store the declarations that
will be used to transform the raw literal into the complete
literal. SILGen will form the appropriate calls. This representation
is far simpler---the AST no longer has a bunch of implicit nodes---and
doesn't break AST invariants.
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.
When we are type-checking calls, subscripts, or other call-like
expressions, use the argument labels provided by the various
expression nodes rather than those encoded in the tuple type. This
means that argument label matching now matches the callee
declaration's argument labels against the argument labels, without
relying on encoding the argument labels within types in the AST.
This refactor is a stepping stone torward SE-0111.
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.
This removes the logic which issued warnings when accessing enum
elements as instance members (SE-0036), making room for a new
implementation that will issue errors instead.
This reverts commit ae1058a39a.
Code completion had the ability to use declarations to provide better
code completion results for postfix completions, e.g., calls to
functions/methods, but it wasn't trying to get these declarations from
anywhere. Now, get these declarations from the solution to the
constraint system.
The impetus for this is to use default-argument information from the
declaration rather than the type, but plumbing this information
through also means that we get proper "rethrows" annotations, covered
by <rdar://problem/21010193>, and more specific completions in a
number of other places.
Fixes <rdar://problem/21010193>.
Rather than relying on the embedding of default argument information
into tuple types (which is gross), make sure that the various clients
(type checker, type checker diagnostics, constraint application) can
dig out the callee declaration and retrieve that information from
there.
We already have detailed knowledge of Optional's layout in SILGen, so these intrinsics were almost unused. They were only used in a few obscure places by some optional-to-bool conversions, used by 'is [A]' collection tests and the codegen for 'lazy' properties. Change these over to generate an EnumIsCaseExpr that we can directly lower to a 'select_enum' instruction in SILGen, leading to better codegen and obviating the need for these intrinsic functions.
Whenever we have a call, retrieve the argument labels from the
argument structurally and associate them with the callee. We were
previously doing this as a separate AST walk (which was unnecessary),
so fold that into constraint generation for a CallExpr.
This is a slightly-pared-back version of
3753d779bc that isn't so rigid in its
interpretation of ASTs. I'll tighten up the semantics over time.
Whenever we have a call, retrieve the argument labels from the
argument structurally and associate them with the callee. We were
previously doing this as a separate AST walk (which was unnecessary),
so fold that into constraint generation for a CallExpr. We were also
allowing weird ASTs to effectively disable this information: tighten
that up and require that CallExprs always have a ParenExpr, TupleExpr,
or (as a temporary hack) a TypeExpr whose representation is a
TupleTypeRepr as their argument prior to type checking. This gives us
a more sane AST to work with, and guarantees that we aren't losing
label information.
From the user perspective, this should be NFC, because it's mostly AST
cleanup and staging.
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.
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
- Fix SR-1112, where the fixit would eat all characters in the RHS expression except for the last one due to improper SourceRange math.
- Noticed by inspection, an expression undergoing an implicit conversion (such as a load from an optional `var`) would be judged as requiring parens, when that's really unnecessary.
The most recent LLVM update brought in support for more than two types of trailing objects,
so we can use the template for TupleExpr now too.
No functionality change.
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.
UnresolvedConstructorExpr is not providing any value here; it's
essentially just UnresolvedDotExpr where the name refers to an
initializer, so use that instead. NFC
It is a common point of confusion that property initializers cannot access self, so
produce a tailored diagnostic for it.
Also, when building implicit TypeExprs for the self type, properly mark them implicit.
