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
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 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
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
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
A failable initializer that ended in an unconditional 'return nil' was leaving the exit basic block unemitted, since we exited early before writing out the unreachable epilog. Thanks Chris for catching this.
Swift SVN r21491
Since we preserve a single exit point in SIL, provide a join point with a BB argument to receive the success or failure result to return.
Swift SVN r21450
Introduce an attribute that describes when a given CF type is
toll-free-bridged to an Objective-C class, and which class that
is. Use that information in the type checker to provide the CF <->
Objective-C toll-free-bridged conversions directly, rather than using
the user-defined conversion machinery.
Swift SVN r21376
This allows UnicodeScalars to be constructed from an integer, rather
then from a string. Not only this avoids an unnecessary memory
allocation (!) when creating a UnicodeScalar, this also allows the
compiler to statically check that the string contains a single scalar
value (in the same way the compiler checks that Character contains only
a single extended grapheme cluster).
rdar://17966622
Swift SVN r21198
r21096 introduces an optimization barrier for failing initializers
that allows the pattern
let x: NSFoo? = NSFoo()
be used to detect whether NSFoo() returned nil, even though the type
system says it cannot. Extend this check to Objective-C methods and
properties, where the non-optional annotation may be incorrect
<rdar://problem/17984530>.
Swift SVN r21176
If we see that we're injecting the result of an @objc initializer into an optional, perform the T -> T? conversion using unchecked_ref_bit_cast, which is opaque to the optimizer, instead of doing a proper optional injection. This prevents the optimizer from defeating our workaround for failing initializers. <rdar://problem/17941601>
Swift SVN r21096
as a std::vector<std::unique_ptr<PathComponent>>. DiverseList memcpy's
around its buffer on copy and move operations. This seems safe with all
of the current implementations of Cleanup, but is absolutely not with the
LValue PathComponents. These things hold std::vectors, RValue (which has
an std::vector in it), and a bunch of other probably non-trivial things.
While we're in here, disable the copy constructor, since it isn't safe.
This doesn't harm mainline, but was burning me on a patch I'm working on.
When/if someone cares about performance optimizing this code, a better
approach would be to use an ilist + bump pointer allocator.
Swift SVN r21057
behaviorly correct code by CSE'sing subscripts that are identical.
Also, add a dump() method to PathComponent to help visualize / debug LValue structures.
Swift SVN r20661
computed property" errors when SILGen could determine that there was
an inout writeback alias, and have the code instead perform CSE of the
writebacks directly.
This means that we produce more efficient code, that a lot of things
now "just work" the way users would expect, and that the still erroneous
cases now get diagnosed with the "inout arguments are not allowed to
alias each other" error, which people have a hope of understanding.
There is still more to do here in terms of detecting identical cases,
but that was true of the previous diagnostic as well.
Swift SVN r20658
getNextUncurryLevelRef was using it's own local test to determine whether a
FuncDecl is dynamically dispatched (which didn't check for "final"), change it
to use SILGenFunction::getMethodDispatch instead.
Swift SVN r20623
Factor out the code for emitting the "bind" branching logic, and share it to implement an LValueComponent for optional binds, which makes optional assignments work.
Swift SVN r20614
Expose Substitution's archetype, replacement, and conformances only through getters so we can actually assert invariants about them. To start, require replacement types to be materializable in order to catch cases where the type-checker tries to bind type variables to lvalue or inout types, and require the conformance array to match the number of protocol conformances required by the archetype. This exposes some latent bugs in the test suite I've marked as failures for now:
- test/Constraints/overload.swift was quietly suffering from <rdar://problem/17507421>, but we didn't notice because we never tried to codegen it.
- test/SIL/Parser/array_roundtrip.swift doesn't correctly roundtrip substitutions, which I filed as <rdar://problem/17781140>.
Swift SVN r20418
The type checker produces nested optional evaluations for expressions of the form 'x.optionalProperty?.optionalProperty as NonOptionalType'. SILGen had a peephole for this case that was apparently never tested, because we tried to dereference a null failure BB. Fixes <rdar://problem/17576873> and at least half a dozen dupes. The codegen is still kind of ridiculous, but correct.
Swift SVN r20358
introduced, as these are obvious miscompilations and clearly mystifying to our user base.
This is enough to emit diagnostics like this:
writeback_conflict_diagnostics.swift:58:70: error: inout writeback aliasing conflict detected on computed property 'c_local_struct_property'
swap(&c_local_struct_property.stored_int, &c_local_struct_property.stored_int)
~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
writeback_conflict_diagnostics.swift:58:33: note: concurrent writeback occurred here
swap(&c_local_struct_property.stored_int, &c_local_struct_property.stored_int)
~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
which isn't great, but is better than nothing (better wording is totally welcome!).
This doesn't handle subscripts (or many other kinds of logical lvalue) at all yet, so
it doesn't handle the swift WTF case, but this is progress towards that.
Swift SVN r20297
to give it a trivial amount of CSE. This isn't important generally (global_addr turns into
a trivial constant in LLVM IR) but unblocks some other SILGen stuff I'm working on.
This doesn't affect lazy global addressors.
Swift SVN r20259
If a dynamic definition overrides a non-dynamic one, then we need to go through objc_msgSend even if we try vtable dispatch on the non-dynamic superclass definition. Also, if we have a dynamic definition that doesn't override, we don't need a vtable entry for it at all.
Swift SVN r19944
Mechanically add "Type" to the end of any protocol names that don't end
in "Type," "ible," or "able." Also, drop "Type" from the end of any
associated type names, except for those of the *LiteralConvertible
protocols.
There are obvious improvements to make in some of these names, which can
be handled with separate commits.
Fixes <rdar://problem/17165920> Protocols `Integer` etc should get
uglier names.
Swift SVN r19883
The witness table entry needs to dispatch through the ObjC entry point if the witness is dynamic. Slot this into the existing code path by consing up a small transparent thunk to exercise the existing code paths for adjusting calling convention from ObjC to Swift.
Swift SVN r19864
Introduce the new BooleanLiteralConvertible protocol for Boolean
literals. Take "true" and "false" as real keywords (which is most of the
reason for the testsuite churn). Make Bool BooleanLiteralConvertible
and the default Boolean literal type, and ObjCBool
BooleanLiteralConvertible. Fixes <rdar://problem/17405310> and the
recent regression that made ObjCBool not work with true/false.
Swift SVN r19728
