Previously we treated the * platform as checking for the minimum
deployment target, but that's definitely unnecessary.
There is a bit of a hack here to avoid diagnosing the 'else' branch as
unreachable: if a constant true/false came from #available, ignore it.
This is where the AllowLoweredTypes flag to Type::subst() is important,
since this function is used on both canonical AST types, and lowered
AST types.
When visited by an ASTWalker, an if_expr nested within a
patter_binding_decl has no Parent. This leads to a crash while assigning
counters for the if_expr's "else" branch: there is no enclosing region,
so grabbing the current region is impossible.
We can handle this case safely by using a new leaf counter for the
"else" branch.
Swift PR-1116, rdar://problem/23256795
As part of SE-0022, introduce an 'objc_selector' encoding for string
literals that places the UTF-8 string literal into the appropriate
segment for uniquing of Objective-C selector names.
The following patch introduced a regression where materializeForSet
did not invoke didSet/willSet for stored properties with observers:
<249242b08d>
The old SILGen materializeForSet was only used for witness thunks,
where it used Ordinary access semantics for the storage.
When I switched over to using the new materializeForSet implementation
for static thunks too, I added some logic to use DirectToStorage access
semantics where appropriate, however this was wrong for observable
properties, which need DirectToAccessor semantics.
Fixes <rdar://problem/24315392>.
We always passed nullptr to getMaterializeForSetCallbackType(), so
I'm assuming it is safe to just delete this bit of dead code.
Now the only remaining usages of PolymorphicFunctionType in SIL are
assertions ensuring that PolymorphicFunctionType doesn't end up there.
There are still a number of usages of AllArchetypes though, via
SILFunction::ContextGenericParams. Once @rjmccall finishes the
heavy lifting on the IRGen side, it should be pretty easy to rip
these out from SIL, too.
When compiling a module with multiple FileUnits (eg, while running
swiftc without -whole-module-optimization), we emit all decls
in the ExternalDeclarations list for every FileUnit, leading to
duplicate symbols if any of those decls were public.
Joe's workaround skipped decls on ExternalDefinitions that were
already emitted in the current FileUnit, but that was not sufficient;
the right fix is to not put stuff on ExternalDeclarations at all,
if we're going to emit it as part of a decl inside our file.
In this case, the synthesized _code accessors for an ErrorType
conformance do not belong in ExternalDefinitions, because they're
part of an ExtensionDecl that is in the current FileUnit.
Finally add some tests for this stuff, because it appears our
existing coverage was insufficient.
If you extend a C/ObjC enum type to conform to ErrorType, then the synthesized _code getter ends up registered as an external decl, but appears to already get synthesized due to @slavapestov's changes. I'm not sure whether this is reliable enough that we can simply stop registering the external decls, so just to keep the build from crashing, insert a check in emitExternalDecls that we didn't already emit the decl and skip emission. Low-risk workaround for rdar://problem/24287125.
As there are no instructions left which produce multiple result values, this is a NFC regarding the generated SIL and generated code.
Although this commit is large, most changes are straightforward adoptions to the changes in the ValueBase and SILValue classes.
weak copies for capture list variables. Other wise two variables with
identical names will end up in the same scope.
This fixes a crash in the compiler.
rdar://problem/24150188
SR-526
The original implementation of SILGenMaterializeForSet.cpp did not
support the case where SelfInterfaceType contained a generic
parameter. Recent changes to switch SILGen to always open-code
materializeForSet, and Sema to always emit accessors, exposed this
in validation-tests.
And use the new project_existential_box to get to the address value.
SILGen now generates a project_existential_box for each alloc_existential_box.
And IRGen re-uses the address value from the alloc_existential_box if the operand of project_existential_box is an alloc_existential_box.
This lets the generated code be the same as before.
If we're accessing a field of a struct, ignore materializeForSet;
it will only have been synthesized if the struct conforms to a
protocol, and we don't want the presence of a conformance to
affect generated code.
A more principled fix would change the SILGen logic to use a
materializeForSet if it would have been synthesized anyway,
asserting that it was synthesized in that case. I'll clean this
up in the 'master' branch once these fixes settle.
When the nearest implementation of a superclass's implementation of a
method is in the same module, eagerly emit a direct call to the method
instead of relying on the devirtualizer for these, since this is a very
lightweight check and can make -Onone builds faster.
This change is needed for the next update to ToT LLVM. It can be put
into place now without breaking anything so I am committing it now.
The churn upstream on ilist_node is neccessary to remove undefined
behavior. Rather than updating the different ilist_node patches for the
hacky change required to not use iterators, just use iterators and keep
everything as ilist_nodes. Upstream they want to eventually do this, so
it makes sense for us to just do it now.
Please do not introduce new invocations of
ilist_node::get{Next,Prev}Node() into the tree.
And use project_box to get to the address value.
SILGen now generates a project_box for each alloc_box.
And IRGen re-uses the address value from the alloc_box if the operand of project_box is an alloc_box.
This lets the generated code be the same as before.
Other than that most changes of this (quite large) commit are straightforward.
Now that all the pieces are in place, we can finally start seeing
some benefits. In particular, the code for witness thunk emission
is much simpler now.
My recent changes added "resiliently-sized" global variables, where a
global in one module is defined to be of a type from another module,
and the type's size is not known at compile time.
This patch adds the other half of the equation: when accessing a
global variable defined by another module, we want to use accessors
since we want to resiliently change global variables from stored to
computed and vice versa.
The main complication here is that the synthesized accessors are not
part of any IterableDeclContext, and require some special-casing in
SILGen and Serialization. There might be simplifications possible here.
For testing and because of how the resilience code works right now,
I added the @_fixed_layout attribute to global variables. In the
future, we probably will not give users a way to promise that a
stored global variable will always remain stored; or perhaps we will
hang this off of a different attribute, once we finalize the precise
set of attributes exposed for resilience.
There's probably some other stuff with lazy and observers I need to
think about here; leaving that for later.
This removes the -use-native-super-method flag and turns on dynamic
dispatch for native method invocations on super by default.
rdar://problem/22749732
- isTypeParameter() -- check if this is an archetype or dependent
interface type.
- requiresClass() -- check if this is a class-constrained type
parameter.
The old isOpaque() check has been replaced by
(isTypeParameter() && !requiresClass(moduleDecl)).
This allows us to pass the ModuleDecl on down to
GenericSignature::requiresClass(), enabling the use of
interface types in abstraction patterns.
NFC for now.
