Recently I changed Sema to always emit materializeForSet for properties
of structs, to fix issues with duplicate or missing symbols when the
type declaration and conformance are in different translation units.
The same issue can happen with properties of final classes and enums,
so let's simplify the logic by always emitting a materializeForSet
when possible.
The new multifile demonstrate the problem.
Allow a behavior protocol to declare an `initStorage` implementation with a parameter. If we have an initializer expression, use `initStorage(initExpr)` to initialize the storage; otherwise, remember the storage declaration and its initializer. Definite
initialization will have to use these to insert the initialization operation for the behavior property at the right place.
This reorganization allows adding attributes that refer to types.
I need this for a @_specialize attribute with a type list.
PrintOptions.h and other headers depend on these enums. But Attr.h
defines a lot of classes that almost never need to be included.
If a behavior protocol requires an `initialValue` static property, satisfy the requirement using the initial value expression from the property declaration. This lets us implement `lazy` as a property behavior.
Fix some interface type/context type confusion in the AST synthesis from the previous patch, add a unique private mangling for behavior protocol conformances, and set up SILGen to emit the conformances when property declarations with behaviors are visited. Disable synthesis of the struct memberwise initializer if any instance properties use behaviors; codegen will need to be redesigned here.
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.
There's a group of methods in `DeclContext` with names that start with *is*,
such as `isClassOrClassExtensionContext()`. These names suggests a boolean
return value, while the methods actually return a type declaration. This
patch replaces the *is* prefix with *getAs* to better reflect their interface.
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
This reverts commit 2b6ab633fc because it
at least breaks:
Swift :: stdlib/SequenceType.swift.gyb
and possibly also results in some or all of these failures:
Swift :: compiler_crashers/27944-swift-astvisitor.swift
Swift :: compiler_crashers/28200-swift-typebase-getdesugaredtype.swift
Swift :: stdlib/CollectionType.swift.gyb
Swift :: stdlib/MicroStdlib.swift
This fixes the issue that "SILGen: Correctly emit accessors synthesized to
witness protocol requirements" was meant to solve, but in a simpler way.
A better fix would be to first address the issue where @_transparent
function bodies are not serialized in some cases, and then only emit
synthesized accessors as needed, in the original version of this patch.
To fix the duplicate symbol issues, we would emit the synthesized
accessors with shared linkage, which would always work once serialized
bodies were available.
For resilient structs of course, we'll always need to emit accessors
anyway.
With an upcoming patch we would call setMutating() on materializeForSet
before computing the setter's isMutating() in the case where a setter
was explicitly declared 'nonmutating'.
Fix that by replacing the setter->isMutating() call with a direct
computation of the expected result.
It seems that the materializeForSet of protocol protocol requirements
has to be mutating, even if the protocol is a class protocol or the
property is nonmutating -- I need to investigate why and fix SILGen
to not make this assumption, but in the meantime, opt-out of the
new logic with protocol requirements to avoid more breakage.
My recent changes added "resiliently-sized" global variables, where a
global in one module is defined to be of a type from another module,
and the type's size is not known at compile time.
This patch adds the other half of the equation: when accessing a
global variable defined by another module, we want to use accessors
since we want to resiliently change global variables from stored to
computed and vice versa.
The main complication here is that the synthesized accessors are not
part of any IterableDeclContext, and require some special-casing in
SILGen and Serialization. There might be simplifications possible here.
For testing and because of how the resilience code works right now,
I added the @_fixed_layout attribute to global variables. In the
future, we probably will not give users a way to promise that a
stored global variable will always remain stored; or perhaps we will
hang this off of a different attribute, once we finalize the precise
set of attributes exposed for resilience.
There's probably some other stuff with lazy and observers I need to
think about here; leaving that for later.
This is a preliminary cleanup before adding resilient access to
global variables. It might also enable @_fixed_layout properties
on resilient structs one day, if we choose to do that.
Also, change NominalTypeDecl::hasFixedLayout() to not care about
classes imported from Clang. IRGen already has its own fine-grained
queries and abstractions for asking this question, so don't try
to capture in the AST.
We weren't adding them as external decls unless they were for
storage on an imported type, which meant SILGen wasn't emitting
them if the conforming type was from a different Swift source
file, or in whole-module mode, a different module. This led
to linker errors.
Instead, always add accessors to the external decl list, but
skip them in SILGen if they are contained in the DeclContext
we are currently emitting (which is a source file or module).
Note that they are still emitted with the wrong linkage, from a
resilience perspective. Clients must only ever see public
exports for getters, setters and materializeForSet emitted
because they are required by resilience or the access pattern;
'accidental' accessors synthesized for protocol conformance
should not be public.
This improves MaterializeForSetEmitter to support emission
of static materializeForSet thunks, as well as witnesses.
This is now done by passing in a nullptr as the conformance
and requirement parameters, and adding some conditional code.
Along the way, I fixed a few limitations of the old code,
namely weak/unowned and static stored properties weren't
completely plumbed through. There was also a memory leak in
addressed materializeForSet, the valueBuffer was never freed.
Finally, remove the materializeForSet synthesis in Sema since
it is no longer needed, which fixes at least one known crash
case.
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.
by changing buildSubscriptIndexReference to work solely in terms of the parameter
pattern of the subscript, instead of trying to walk the index type in parallel to
extract parameter labels.
