the last instruction in the previous basic block.
Previously the location of the condition was reused for this, which caused
really unintuitive stepping behavior in the debugger.
<rdar://problem/18433491> Stepping order doesn't match developer expectations
Swift SVN r22269
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
This patch adds the ability (-enable-experimental-unavailable-as-optional) to
treat potentially unavailable declarations as if they had optional types. For
the moment, this is only implemented for global variables.
The high-level approach is to (1) record the potential unavailability of a
declaration reference in the overload choice during constraint generation; (2)
treat the declaration as if it had an optional type during overload resolution
(this is similar to how optional protocol members are treated); and (3) add an
implicit conversion (UnavailableToOptionalExpr) during constraint application
to represent the run-time availability check and optional injection.
This patch does not implement SILGen for UnavailableToOptionalExpr.
Swift SVN r22245
Addressors now appear to pass a simple smoke-test; in
order to allow some parallel developement, I'll be
committing actual SILGen tests for this later and
separately.
Swift SVN r22243
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
Use this in calls to TypeBase::getTypeOfMember() that were relying on
archetypes solely because they were using EnumElementDecl::getArgumentType().
Swift SVN r22205
The metatype is associated with the formal AST type of the value, not whatever lowered SIL type we happen to have lying around. Adjust the SIL verifier to check that value_metatype instructions produce a metatype for which the instance is a potential lowering rather than by exact type match. This lets us take the metatype of metatypes (and incidentally, of functions, and of tuples thereof), fixing rdar://problem/17242770.
Swift SVN r22202
accessors on non-dynamic storage.
This allows us to take advantage of dynamic knowledge
that a property is implemented as stored in order to
gain direct access to it instead of copying into a
temporary. When a class or protocol-member property
is expensive to copy, and particularly when it's of
copy-on-write type, such direct accesses can massively
improve the performance of a program.
We are currently only able to apply this when the
property is implemented purely as stored. A willSet
observer inherently blocks the optimization, but we
should be able to make it work even for properties
with didSet observers. This could be done by returning
an arbitrary callback from materializeForSet instead
of returning a flag indicating whether to call the
setter.
rdar://17416120
Swift SVN r22122
materializeForSet accessors for stored properties.
Also, reliably place materializeForSet after the
setter, no matter when we generate it.
Swift SVN r22014
We emit initializer expressions once for every init definition, which caused us to try to emit the same symbol for closure bodies in initializers multiple times. Fixes rdar://problem/17971234.
Swift SVN r21997
- A spot fix in SILGen for reabstracting the result of a downcast, which fixes checked casts to function types.
- Associate the layout information in type metadata records with the most abstract representation of the type. This is the correct thing to do in cases where we need the metadata as a tag for an opaque value--if we store a value in an Any, or pass it as an unconstrained generic parameter, we must maximally reabstract it. This fixes the value semantics of existentials containing trivial metatypes.
- To ensure that we get runtime layout of structs and enums correct when they contain reabstractable types, introduce a "metadata for layout" concept, which doesn't need to describe the canonical metadata for the type, but only needs to describe a type with equivalent layout and value semantics. This is a correctness fix that allows us to correctly lay out generic types containing dependent tuples and functions, and although we don't really take advantage of it here, it's also a potential runtime performance win down the road, because we could potentially produce direct metadata for a primitive type that's layout-equivalent with a runtime-instantiated type. To aid in type safety here, push SILType deeper into IRGen in places where we potentially care about specific representations of types.
- Finally, fix an inconsistency between the runtime and IRGen's concept of what spare bits unmanaged references and thick metatypes have.
Together, these fixes address rdar://problem/16406907, rdar://problem/17822208, rdar://problem/18189508, and likely many other related issues, and also fixes crash suite cases 012 and 024.
Swift SVN r21963
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
This patch adds a new 'pound_os' token, a new case for it in parseExprPostfix, and parsing of platform version constraints, e.g., OSX >= 10.10.
It also adds enough type checking and SILGen to get the parsing tests to run without triggering "Unimplemented" assertions.
Swift SVN r21865
This is necessary to be able to properly stash values with nontrivial lowerings, such as metatypes and functions, inside existential containers. Modify SILGen to lower values to the proper abstraction level before storing them in an existential container. Part of the fix for rdar://problem/18189508, though runtime problems still remain when trying to actually dynamicCast out a metatype from an Any container.
Swift SVN r21830
A failable initializer can satisfy a failable initializer requirement
(regardless of whether either is spelled with init! or
init?). Handle the optional translation within the witness.
Additionally, a failable initializer requirement spelled with
"init!" can satisfy a non-failable initializer requirement, in which
case we force the optional within the witness.
Swift SVN r21812
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
This commit adds a new expression (AvailabilityQueryExpr) and a single kind of
specification for when a block of code or function is available
(VersionConstraintAvailabilitySpec). We may add more kinds of specifications
in the future. At the moment, the AvailabilityQueryExpr allows only a
single platform to be queried; I will add support for multiple platforms
in a later commit.
This commit contains just the added AST nodes; no parsing, type checking, etc.
I’ve added assert(false && “Unimplemented”) for places where support for
AvailabilityQueryExpr will need to be added later.
Swift SVN r21760
This fix should also extend to the general case of witnesses that return non-optional for optional-returning requirements, when/if we support that.
Swift SVN r21721
This eliminates the workaround for propagating 'nil' from Objective-C
initializers up through Swift initializers, now that failable
initializers handle this propagation.
Swift SVN r21706
A couple of issues here:
- We didn't apply the base metatype when emitting calls to the getter for static properties, causing a crash when references to the accessor are emitted (such as when modeling a protocol requirement)
- We didn't propagate isDirectPropertyAccess through emitRValueDecl, causing the getter to recursively call itself when it was emitted successfully.
Together these fix rdar://problem/17986478.
Swift SVN r21695
Avoids creating a dangling stack block reference when working with imported APIs that take blocks as IUOs, fixing rdar://problem/18132853.
Swift SVN r21662
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
Set up the same structure of a failure block and common exit point for class initializers that fail, and fix the codegen for the allocating entry point to use the correct return type when calling a failable initializer.
Swift SVN r21536
- Split getSelfTypeForDynamicLookup into two pieces, and generalize it
to work on non-loadable protocols.
- Change dynamic_method_branch to take its argument as a protocol of any
protocol type, instead of as something of UnownObject type.
- Teach emitForcedDynamicMemberRef to only do its peephole optimization for
@objc cases, since it is special behavior of objc_msgSend.
- enhance emitDynamicPartialApply & emitDynamicMemberRefExpr to emit the
proper project_existential instruction (not a _ref) when dealing with a
non-classbound protocol.
Change the verifier to allow DynamicMethodBranchInst to work on non-@objc
protocol members.
This eliminates a bunch of pointless unchecked_ref_cast's in the generated
SIL for existing code, but this got squashed at IRGen time anyway, so no
real change for anything that sema permits.
Swift SVN r21519
A couple reasons for this:
- How 'self' gets cleaned up is dependent on where the failure occurs. If we propagate failure from a class initializer, the failed 'super.init' or 'self.init' has already cleaned up the object, so we only need to deallocate the box. In cases where we fail explicit, we release 'self', which works out because we're only supporting failure with a fully-initialized object for now.
- This lets us set the location info for the cleanup to the AST node that instigated failure, giving better QoI for DI failures (such as failing with a partially-initialized object).
Swift SVN r21505
