If we have a C function pointer conversion, generate a thunk using the same logic we use for ObjC method thunks, and emit a pointer to that thunk as the C function pointer value. (This works for nongeneric, nonmember functions; generics will additionally need to apply generic parameters within the thunks. Static functions would need to gather the metatype as well.)
Swift SVN r25653
The materializeForSet accessor for a `dynamic` property needs to dynamically invoke the getter and setter of the property in order to allow for runtime modification, so it doesn't need to be dynamically dispatched itself. If the property came from an imported ObjC class, then we can't dynamically dispatch it without polluting the selector namespace. Introduce a new 'ForcedStaticDispatch' bit and set it in order to force `dynamic` materializeForSet accessors to be statically dispatched. (They can't be `final` because it's legal to override a dynamic property.) If the property came from ObjC, register materializeForSet as an external declaration so it gets generated by SIL. Fixes rdar://problem/18706056.
Swift SVN r24930
the call instead of during the formal evaluation of the argument.
This is the last major chunk of the semantic changes proposed
in the accessors document. It has two purposes, both related
to the fact that it shortens the duration of the formal access.
First, the change isolates later evaluations (as long as they
precede the call) from the formal access, preventing them from
spuriously seeing unspecified behavior. For example::
foo(&array[0], bar(array))
Here the value passed to bar is a proper copy of 'array',
and if bar() decides to stash it aside, any modifications
to 'array[0]' made by foo() will not spontaneously appear
in the copy. (In contrast, if something caused a copy of
'array' during foo()'s execution, that copy would violate
our formal access rules and would therefore be allowed to
have an arbitrary value at index 0.)
Second, when a mutating access uses a pinning addressor, the
change limits the amount of arbitrary code that falls between
the pin and unpin. For example::
array[0] += countNodes(subtree)
Previously, we would begin the access to array[0] before the
call to countNodes(). To eliminate the pin and unpin, the
optimizer would have needed to prove that countNodes didn't
access the same array. With this change, the call is evaluated
first, and the access instead begins immediately before the call
to +=. Since that operator is easily inlined, it becomes
straightforward to eliminate the pin/unpin.
A number of other changes got bundled up with this in ways that
are hard to tease apart. In particular:
- RValueSource is now ArgumentSource and can now store LValues.
- It is now illegal to use emitRValue to emit an l-value.
- Call argument emission is now smart enough to emit tuple
shuffles itself, applying abstraction patterns in reverse
through the shuffle. It also evaluates varargs elements
directly into the array.
- AllowPlusZero has been split in two. AllowImmediatePlusZero
is useful when you are going to immediately consume the value;
this is good enough to avoid copies/retains when reading a 'var'.
AllowGuaranteedPlusZero is useful when you need a stronger
guarantee, e.g. when arbitrary code might intervene between
evaluation and use; it's still good enough to avoid copies
from a 'let'. The upshot is that we're now a lot smarter
about generally avoiding retains on lets, but we've also
gotten properly paranoid about calling non-mutating methods
on vars.
(Note that you can't necessarily avoid a copy when passing
something in a var to an @in_guaranteed parameter! You
first have to prove that nothing can assign to the var during
the call. That should be easy as long as the var hasn't
escaped, but that does need to be proven first, so we can't
do it in SILGen.)
Swift SVN r24709
It was checking the current function's transparency rather than the
referenced function's transparency.
Fixing this did not seem to have a measureable impact on the performance
of -Onone code.
Fixes rdar://problem/19477711.
Swift SVN r24452
For now, conservatively retain them so they can be forwarded as +1 values, until we can push +0 rvalue support down into the forwarding and function application implementations. Preserve the old, technically incorrect behavior unless -enable-guaranteed-self is enabled to avoid punishing -Onone code until guaranteed self is enabled. (With guaranteed self and +0 rvalue support, the overhead this introduces should be avoidable in the code generator.)
Swift SVN r24374
as passing self by value, not by inout. This is the correct representation at
the AST level, and we now lower self references as the new @in_guaranteed
parameter convention. This allows SIL clients (like DI) to know that a nonmutating
protocol method does not mutate the pointee passed into the method.
This fixes:
<rdar://problem/19215313> let properties don't work with protocol method dispatch
<rdar://problem/15821762> Self argument of generic curried nonmutating instance methods is inout
Swift SVN r23864
isn't used yet, but will be for modeling the self argument passed to an
address-only witness implementation. NFC since all this code is dead :-)
Swift SVN r23857
Fixes a bug where dynamic dispatches of class methods or initializers through generic interfaces didn't redispatch to subclasses. Also fix up some logic errors noticed by inspection.
Swift SVN r22945
When we've already established that the optional has a value, using unchecked_take_enum_data_addr to directly extract the enum payload is sufficient and avoids a redundant call and check at -Onone. Keep using the _getOptionalValue stdlib function for checked optional wrapping operations such as "x!", so that the stdlib can remain in control of trap handling policy.
The test/SIL/Serialization failures on the bot seem to be happening sporadically independent of this patch, and I can't reproduce failures in any configuration I've tried.
Swift SVN r22537
When we've already established that the optional has a value, using unchecked_take_enum_data_addr to directly extract the enum payload is sufficient and avoids a redundant call and check at -Onone. Keep using the _getOptionalValue stdlib function for checked optional wrapping operations such as "x!", so that the stdlib can remain in control of trap handling policy.
Swift SVN r22533
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
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
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
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 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
completely destroyed when forwarded.
Also, make forwarding a cleanup a first-class operation
on cleanups, rather than setting the cleanup state directly.
Swift SVN r19332
unconditional_dynamic_cast_addr instruction.
Also, fix some major semantic problems with the
existing specialization of unconditional dynamic
casts by handling optional types and being much
more conservative about deciding that a cast is
infeasible.
This commit regresses specialization slightly by
failing to turn indirect dynamic casts into scalar
ones when possible; we can fix that easily enough
in a follow-up.
Swift SVN r19044
Maybe we should wrap the @objc dispatch in another thunk in order to account for ObjC dynamic magic, but this is the shortest path to getting proper class dispatch behavior for witnesses in all cases and close <rdar://problem/14620454>.
Swift SVN r17757
This ensures that if the witness is a foreign-to-native, curry, or other lazily-generated thunk, that the thunk gets generated. This fixes natively-ObjC witnesses to Swift protocols.
Swift SVN r17739
r15824 overrode SILVerifier::visitSILBasicBlock without calling up to the super definition, causing us to never actually verify any instructions for the past three weeks. Awesome. Patch up the latent bugs that have crept in, except for three devirtualizer tests that fail. This doesn't reenable the verifier because I don't want to cause crashes until all the regressions have been cleared up.
Swift SVN r17121
inherited conformances can result in virtual calls to overriding
subclass methods.
Previously given the following swift code:
protocol P {
func x()
}
class B : P {
func x() { ... }
}
class B2 : B {
func x() { ... }
}
func doX<T : P>(t : T) {
t.x()
}
var b2 = B2()
doX(b2)
We would have b2 reference the protocol method for B.x. But since the
protocol method B.x would have a direct function reference to B.x, we
would not get the correct behavior that doX(b2) should invoke B2.x. This
is fixed by changing SILGen to emit class_method calls in protocol
methods for classes.
Swift SVN r16645
Do this the lazy way, just autoreleasing "self" after the call. A future optimization pass may be able to eliminate this autorelease when it recognizes the lifetime of the derived value, but that's not immediately necessary.
Swift SVN r16635
This will represent the return convention of imported __attribute__((objc_returns_inner_pointer)) methods. Leave it unimplemented for now until we can autorelease things sanely.
Swift SVN r16628
Emit Swift thunk functions to bridge blocks into native function values. On entry into @objc thunks, copy_block blocks to ensure they've been lifted off the stack.
Swift SVN r16177
These bits are orthogonal to each other, so combine them into one, and diagnose attempts to produce a type that's both. Spot-fix a bunch of places this revealed by inspection that we would have crashed in SILGen or IRGen if blocks were be handled.
Swift SVN r16088
Language features like erasing concrete metatype
values are also left for the future. Still, baby steps.
The singleton ordinary metatype for existential types
is still potentially useful; we allow it to be written
as P.Protocol.
I've been somewhat cavalier in making code accept
AnyMetatypeType instead of a more specific type, and
it's likely that a number of these places can and
should be more restrictive.
When T is an existential type, parse T.Type as an
ExistentialMetatypeType instead of a MetatypeType.
An existential metatype is the formal type
\exists t:P . (t.Type)
whereas the ordinary metatype is the formal type
(\exists t:P . t).Type
which is singleton. Our inability to express that
difference was leading to an ever-increasing cascade
of hacks where information is shadily passed behind
the scenes in order to make various operations with
static members of protocols work correctly.
This patch takes the first step towards fixing that
by splitting out existential metatypes and giving
them a pointer representation. Eventually, we will
need them to be able to carry protocol witness tables
Swift SVN r15716
We won't have any types where copying has an effect on the bit pattern (except for blocks, which need special handling anyway), and copy_value having a result makes optimizations more complex, so remove it.
Swift SVN r15640
accessors.
Optimize these accessors by making them check for
BoundGenericXType instead of BoundGenericType and dyn_cast'ing
the Decl. (The latter used to be necessary before we split
BoundGenericType.)
Swift SVN r15037
Don't try to set the generic params of a reabstraction thunk until we've established it hasn't already been defined, fixing an issue where the same generic reabstraction pattern occurred in different contexts and we ended up clobbering the archetypes of a thunk that was already defined in terms of other archetypes.
Swift SVN r13964
We still glue the generic params of the requirement to the generic params of the conformance, but now we do it without relying on TypeLowering.
Swift SVN r13771
Pass the context generic params for a reabstraction thunk down to getOrCreateReabstractionThunk from the enclosing function, where it can either use them to define a new thunk or ignore them if it has an equivalent thunk already. Tweak the mangling of reabstraction thunks to use the generic signature with decontextualized "from" and "to" types instead of the generic param list.
Swift SVN r13763
There are some straggling references to the context generic param list, but nothing uses the non-interface param or result types anymore!
Swift SVN r13725
