Extend the handling of function reference kinds to member references
(e.g., x.f), and therefore the logic for stripping argument labels. We
appear to be stripping argument labels from all of the places where it
is required.
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.
What I've implemented here deviates from the current proposal text
in the following ways:
- I had to introduce a FunctionArrowPrecedence to capture the parsing
of -> in expression contexts.
- I found it convenient to continue to model the assignment property
explicitly.
- The comparison and casting operators have historically been
non-associative; I have chosen to preserve that, since I don't
think this proposal intended to change it.
- This uses the precedence group names and higherThan/lowerThan
as agreed in discussion.
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>.
If a behavior has storage that can be initialized out-of-line, generate code in SILGen that uses stores to mark_uninitialized_behavior for eventual analysis by DI.
This is incomplete, particularly, it's missing code generation of glue thunks for accessors that require reabstraction, but I wanted to make sure the progress here didn't bitrot.
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
as well as on parameter decls. Also, tighten up the type checker to look at
parameter types instead of decl attributes in some cases (exposing a type
checker bug).
Still TODO:
- Reject autoclosure/noescape on non-parameter types.
- Move stdlib and other code to use noescape and autoclosure in the right
spot.
- Warn about autoclosure/noescape on parameters decls, with a fixit to move it.
- Upgrade the warning to an error.
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.
Parse 'var [behavior] x: T', and when we see it, try to instantiate the property's
implementation in terms of the given behavior. To start out, behaviors are modeled
as protocols. If the protocol follows this pattern:
```
protocol behavior {
associatedtype Value
}
extension behavior {
var value: Value { ... }
}
```
then the property is instantiated by forming a conformance to `behavior` where
`Self` is bound to the enclosing type and `Value` is bound to the property's
declared type, and invoking the accessors of the `value` implementation:
```
struct Foo {
var [behavior] foo: Int
}
/* behaves like */
extension Foo: private behavior {
@implements(behavior.Value)
private typealias `[behavior].Value` = Int
var foo: Int {
get { return value }
set { value = newValue }
}
}
```
If the protocol requires a `storage` member, and provides an `initStorage` method
to provide an initial value to the storage:
```
protocol storageBehavior {
associatedtype Value
var storage: Something<Value> { ... }
}
extension storageBehavior {
var value: Value { ... }
static func initStorage() -> Something<Value> { ... }
}
```
then a stored property of the appropriate type is instantiated to witness the
requirement, using `initStorage` to initialize:
```
struct Foo {
var [storageBehavior] foo: Int
}
/* behaves like */
extension Foo: private storageBehavior {
@implements(storageBehavior.Value)
private typealias `[storageBehavior].Value` = Int
@implements(storageBehavior.storage)
private var `[storageBehavior].storage`: Something<Int> = initStorage()
var foo: Int {
get { return value }
set { value = newValue }
}
}
```
In either case, the `value` and `storage` properties should support any combination
of get-only/settable and mutating/nonmutating modifiers. The instantiated property
follows the settability and mutating-ness of the `value` implementation. The
protocol can also impose requirements on the `Self` and `Value` types.
Bells and whistles such as initializer expressions, accessors,
out-of-line initialization, etc. are not implemented. Additionally, behaviors
that instantiate storage are currently only supported on instance properties.
This also hasn't been tested past sema yet; SIL and IRGen will likely expose
additional issues.
This class formalizes the common case of the "trailing allocation" idiom we use
frequently. I didn't spot any true bugs while making this change, but I did see
places where we were using the wrong pointer type or casting through void* for
no good reason. This will keep us honest.
I'll get to the other libraries soon.
TypeAlignments.h predates this whole mess; it was used for types with
stronger alignment in PointerLikeTypeTraits than the old default of
"2 by fiat and assumption". All remaining forward-declared types are
AST types, so fold them into TypeAlignments.h.
(The one exception is SILTypeList.h, but that's already gone on master.)
To avoid future ODR issues, explicitly include TypeAlignments.h into
every header that defines a type it forward-declares.
I wish we could use partial specialization to provide PointerLikeTypeTraits
for all derived classes of Decl, TypeBase, etc, but that's not something
you can do in C++ if you don't control the traits class.
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
