Specifically, make sure that any all function_refs produced by the devirtualizer inside fragile functions never reference a private or hidden symbol.
For example, the transparent function body can’t expose private symbols to other modules that may try to inline it.
rdar://21408247
Swift SVN r29405
The devirtualizer was not handling the case, where an overriding method would return a non-optional result, whereas the overridden method from a superclass returns an optional result.
This fixes a compiler crash when compiling the internal version of Adventure.
rdar://21254158.
Swift SVN r29329
We enabled support for concrete subclasses of generic base classes recently, but the devirtualizer was not aware of it and crashed in some cases. This patch fixes it and adds a test-case.
Swift SVN r28636
This fixes a crash compiling test/Interpreter/failable_initializers.swift with -O. The patch makes uses of newly allowed upcast instruction between optionals.
rdar://20869036
Swift SVN r28441
In r26152 a crash was fixed that had been introduced by previous
improvements, but as a result of fixing the crash some cases where we
previously devirtualized were disabled with the intent that they would
be reenabled after further refactoring work was completed.
This commit restores that functionality and reenables the tests.
Swift SVN r27575
This is new attribute we're using to coalesce @thin, @objc_block, and @cc, and to extend to new uses like C function pointer types. Parse the new attribute, but preserve support for the old attributes, and print with the old attributes for now to separate out test changes. Migration fixits and test updates to come. I did take the opportunity here to kill off the '@cc(cdecl)' hack for AST-level function pointer types, which are now only spelt with @convention(c).
Swift SVN r27247
Fixed the logic in getSubstitutionsForSuperclass and renamed it into getSubstitutionsForCalleee to better reflect what it does.
rdar://20440616
Swift SVN r27166
We no longer need or use it since we can always refer to the same bit on
the applied function when deciding whether to inline during mandatory
inlining.
Resolves rdar://problem/19478366.
Swift SVN r26534
Currently a no-op, but effective access for entities within the current
module will soon need to take testability into account. This declaration:
internal func foo() {}
has a formal access of 'internal', but an effective access of 'public' if
we're in a testable mode.
Part of rdar://problem/17732115 (testability)
Swift SVN r26472
If we have a witness_method that has no uses after removing the apply
that we've just devirtualized, then remove the witness_method as well.
Some small renaming as well, to be consistent with other functions.
Swift SVN r26342
We only use this within the devirtualizer, and we should never see
devirtualizable calls to explicitly final methods (since we don't create
these during SILGen). This is just future proofing in case that changes.
Swift SVN r26242
Directly devirtualize cases where we can prove the method being invoked
is 'final'.
Previously we were able to do direct devirtualization (as opposed to
speculative) only when we could prove we knew the dynamic
type (e.g. through seeing a metatype instruction).
The code removed from isKnownFinal here was a vestige of previous
mechanical refactoring which made apparent the fact that this case was
not previously being handled.
There were some cases where the speculative devirtualzation code was
also able to prove there was only one alternative, but we really want
cases like this handled through direct devirtualization. It's possible
that the speculative devirtualization code that was catching some cases
like this is no longer useful and could be removed.
Swift SVN r26221
Make the devirtualization functions take the actual type we're
devirtualizing (or speculatively devirutalizing) to, in order to
simplify the handling of metatypes. Remove the ClassDecl parameter from
these functions since it can always be derived from this type.
These changes set things up for more forthcoming improvements to
metatype handling.
As part of this I've simplified the function that determines if a member
is known to be 'final'. My expectation is that this can be further
simplified by removing the type parameter as part of other improvements
to metatype handling.
Swift SVN r26165
This was exposed by a previous change that fixed two other issues, but
introduced this.
I've fixed the crash (rdar://problem/20165943) and added a test case for
it, but one result of the fix is that we'll currently miss a couple of
cases we could devirtualize, and will instead speculatively devirtualize
in these cases.
I've opened a radar so that I can go back and reenable these cases after
further refactoring that will make it simpler to handle these correctly
(rdar://problem/20166171).
Swift SVN r26152
It turns out we're already at a point where we can easily pass the same
data along to the devirtualization functions, and were already passing
some of it.
Swift SVN r26040
Redefine DevirtClassMethodInfo to carry fewer values in an effort to
reduce the coupling between these functions. Long term I expect this
structure to go away, but that is difficult to do without more
refactoring.
Swift SVN r26034
Having the same return type in an overridden class method is the common
case, so put that first, make it an early exit, removing the deeper
indentation on the less common case of different return types.
Swift SVN r26025
No functional change here, and this is not in its final form. This is
just cut/paste/tweak to split the code apart in a first reasonable form.
Swift SVN r25769
