If a subclass overrides methods with variance in the optionality of non-class-type members, emit a thunk to handle wrapping more optional parameters or results and force-unwrapping any IUO parameters made non-optional in the derived. For this to be useful, we need IRGen to finally pay attention to SILVTables, but this is a step on the way to fixing rdar://problem/19321484.
Swift SVN r24705
Have the ArgumentInitVisitor directly bind argument variables to BB arguments, instead of trying to reuse the InitializationForPattern logic used for general variable bindings. That was a nice idea, but it leads to some ugly edge cases because of the many little ways arguments are different from local variable bindings. By getting rid of the abstraction layers, it's easy for argument binding to bind +0 guaranteed or +1 arguments in place when appropriate, avoiding an r/r pair for "let" bindings. It will also let us eliminate some ugly code from variable binding initialization. Should be NFC aside from some harmless reordering of prolog/epilog variable setup.
Swift SVN r24412
Change all the existing addressors to the unsafe variant.
Update the addressor mangling to include the variant.
The addressor and mutable-addressor may be any of the
variants, independent of the choice for the other.
SILGen and code synthesis for the new variants is still
untested.
Swift SVN r24387
We were falling out of sync when there were multiple parameter patterns, or when there were tuple parameters that destructured into multiple BB arguments. Add an assertion that the types match, which should catch a lot bugs most of the time. This gets us to retain-balance @guaranteed parameters in more cases in -enable-guaranteed-self mode.
Swift SVN r24354
clients of CaptureKind by having getDeclCaptureKind map address-only lets onto
Box or NoEscape, instead of having all the clients do it.
Swift SVN r24136
- Introduce a new 'noescape' CaptureKind and have getDeclCaptureKind()
use it for by-address captures in noescape closures.
- Lower NoEscape captures to a simple inout pointer instead of to a
pointer + refcount.
This includes a test of the SILGen produced code itself along with an
integration test that shows that this enables inout deshadowing to remove
shadows that would otherwise have to be preserved due to closures capturing
them.
This can be more aggressive for address-only let constants, but that will
wait for a follow-up patch.
Swift SVN r24135
This lets us remove a few special cases for @NSManaged, and also fixes
some of the special cases that we didn't handle, like rdar://problem/18801796.
Swift SVN r24037
around the brokenness. Revise the logic in LetValueInitialization to be based on structural
properties of the AST instead of PatternKind.
Swift SVN r23957
... now that we have an exquisitely shaved yak.
This provides a simple and uniform model for "let" constants: they are always either
immediately initialized in their declaration, or they are initialized dynamically
exactly once before any use.
This is a simple generalization of our current model for initializers, but enables
the use of let constants in more cases in local context, e.g. patterns like this:
let x : SomeThing
if condition {
x = foo()
} else {
x = bar()
}
use(x)
Previously this would have to be declared a "var" for no good reason: the value is
only ever initialized, never actually mutated.
The implementation of this is reasonably straight-forward now that the infrastructure
is in place: Sema treats 'let' constants as "settable" if they lack an initializer
(either in the declaration or in a non-PBD binding). This exposes them as an lvalue
at the AST level. SILGen then lowers these things to an alloc_stack, and DI enforces
the "initialization only" requirement that it already enforces for uninitialized 'let'
properties in structs/classes.
Swift SVN r23916
"isConstant" distinction. This was an irritating bit of redundant state
that was making the code more complicated. Clients of VarLoc really only
care about "has address" and "has box", not whether the VarLoc came from
a let or var (and if they did, they can ask the VarDecl directly). NFC,
just more "yak shaving" as Doug likes to say.
Swift SVN r23869
them in a more consistent and principled way. Two changes here: MUI is generated
when a vardecl is emitted, not as a separate "MarkPatternUninitialized" pass. Second,
when generating a MUI for self parameters with a temporary alloc_stack (due to the
possibility of superclass remapping of self) emit the MUI on the allocation itself,
not on the incoming argument. This is a lot more consistent (dissolving a bunch of
hacks in DI).
In terms of behavior changes, this only changes the raw sil generated by SILGen and
consumed by DI, so there is no user-visible change. This simply unblocks future work.
Swift SVN r23823
We can't reliably reject raw values in an NS_ENUM's init(rawValue:), because the enum may have SPI or future values we don't statically know about. Fixes https://twitter.com/autorelease/status/524698585406124033
Swift SVN r23817
This means that even though the guaranteed parameter comes in at +0, we
immediately retain it and add a cleanup handler at the end of the function. Once
+0 self has been turned on, I will add a guaranteed optimization that removes
such retains, releases.
Tests will follow with the commit that enables the actual +0 self parameter.
Swift SVN r23627
variable part of the function prologue by omitting its location.
Fixes <rdar://problem/18989457> Xcode 6.2 6C86C (lldb-320.4.157) : po self returns error: Execution was interrupted, reason: EXC_BAD_ACCESS
Swift SVN r23569
It's not always correct to map a Swift Bool back to ObjCBool in C land, since Bool could have originally been a proper _Bool. Pass the clang::Decl down to type lowering so we can recognize this. We still don't have a great solution for block types, because there's no decl to refer to, and Swift's user-level type system erases the distinction between void(^)(_Bool) and void(^)(BOOL). However, this is enough to let us start using C APIs that traffic in _Bool.
Swift SVN r23546
This allows making global addressors fragile (They use globalinit_{token,func} for initialization of globals).
It has no noticable performance impact on our benchmarks, but it removes an ugly hack which explicitly
prevented addressors from being fragile.
Swift SVN r22812
This allows making global addressors fragile (They use globalinit_{token,func} for initialization of globals).
It has no noticable performance impact on our benchmarks, but it removes an ugly hack which explicitly
prevented addressors from being fragile.
Swift SVN r22795
Stub initializers don't get serialized, so this fixes a vtable layout inconsistency when a method of a subclass of a subclass of NSObject is accessed. Fixes rdar://problem/18498385.
Swift SVN r22480
Those destructors are not referenced anywhere else in the SIL, but are used in the metadata
of a class. If they are private then dead function elimination would remove them.
This fixes <rdar://problem/18431856> unreachable executed at GenDecl.cpp:808
Swift SVN r22261
Now the SILLinkage for functions and global variables is according to the swift visibility (private, internal or public).
In addition, the fact whether a function or global variable is considered as fragile, is kept in a separate flag at SIL level.
Previously the linkage was used for this (e.g. no inlining of less visible functions to more visible functions). But it had no effect,
because everything was public anyway.
For now this isFragile-flag is set for public transparent functions and for everything if a module is compiled with -sil-serialize-all,
i.e. for the stdlib.
For details see <rdar://problem/18201785> Set SILLinkage correctly and better handling of fragile functions.
The benefits of this change are:
*) Enable to eliminate unused private and internal functions
*) It should be possible now to use private in the stdlib
*) The symbol linkage is as one would expect (previously almost all symbols were public).
More details:
Specializations from fragile functions (e.g. from the stdlib) now get linkonce_odr,default
linkage instead of linkonce_odr,hidden, i.e. they have public visibility.
The reason is: if such a function is called from another fragile function (in the same module),
then it has to be visible from a third module, in case the fragile caller is inlined but not
the specialized function.
I had to update lots of test files, because many CHECK-LABEL lines include the linkage, which has changed.
The -sil-serialize-all option is now handled at SILGen and not at the Serializer.
This means that test files in sil format which are compiled with -sil-serialize-all
must have the [fragile] attribute set for all functions and globals.
The -disable-access-control option doesn't help anymore if the accessed module is not compiled
with -sil-serialize-all, because the linker will complain about unresolved symbols.
A final note: I tried to consider all the implications of this change, but it's not a low-risk change.
If you have any comments, please let me know.
Swift SVN r22215
materializeForSet accessors for stored properties.
Also, reliably place materializeForSet after the
setter, no matter when we generate it.
Swift SVN r22014
Update SILGen to create SILGlobalVariable and SILGlobalAddrInst instead of
GlobalAddrInst. When we see a definition for a global variable, we create
the corrsponding SILGlobalVariable definition.
When creating SILGlobalVariable from a global VarDecl, we mangle the global
VarDecl in the same way as we mangle it at IRGen. The SILLinkage is also
set in the same way as we set it at IRGen.
At IRGen, we use the associated VarDecl for SILGlobalVariable if it exists,
to have better debugging information.
We set the initializer for SILGlobalVariable definition only.
We also handle SILGlobalAddrInst in various SILPasses, in the similar way
as we handle GlobalAddrInst.
rdar://15493694
Swift SVN r21887
Redefine the RawRepresentable protocol to use an 'init?' method instead of 'fromRaw(Raw)', and a 'raw' get-only property instead of 'toRaw()'. Update the compiler to support deriving conformances for enums and option sets with the new protocol. rdar://problem/18216832
Swift SVN r21762
Fixes rdar://problem/17619178. I can't make a SILGen test case because of rdar://problem/18182969 -- under normal circumstances we appear to produce new conformances for base protocols even when there are conformances in the stdlib we should reuse instead.
Swift SVN r21594
