We used to just use FileContext at deserialization time. That causes
multiple NormalProtocolConformances with the same protocol and type,
but from different modules. And we will have issues at IRGen.
With this commit, we serialize the parent module and deserialize the parent
module, and we are not going to have multiple NormalProtocolConformances with
the same protocol and type.
rdar://16809311
Swift SVN r17675
This allows a loaded swiftmodule to refer to decls that come from a header
imported by the module itself. There's an unfortunate sharing of the
namespace here with any /other/ headers loaded by /other/ modules (including
the module currently being compiled), but that shouldn't be too much of an
issue in practice -- the declarations would need to be compatible anyway if
you were doing the same thing in Objective-C.
More of <rdar://problem/16702101>. This is possibly the end of the compiler
work, but I'd like to add more tests to make sure everything is working.
Swift SVN r17639
This doesn't handle cross-references to decls /loaded/ from the header
just yet, so all that's testable right now is whether the header's imports
are visible from the secondary target (after being imported in response
to loading the serialized module).
More of <rdar://problem/16702101>
Swift SVN r17638
All serialization should go through serialize(). We don't currently support
serializing docs without serializing a module.
Also, tidy up how Serializer is used within Serialization.cpp.
Swift SVN r17637
It's not clear if all of these are always initialized before their
uses, so it seems reasonable to default initialize them to
predictable behavior.
Swift SVN r17612
It is reasonable that one module has a declaration for a SILFunction while
another module has the definition. We return from lookupSILFunction when
we find a definition and keep looking when a declaration is found from
a module.
rdar://16815627
Swift SVN r17586
We were accidentally forcing all members of a class to be instantiated in two places:
- by trying to look up an existing destructor decl in the class, and
- by adding the implicit destructor to the class, because addMember needlessly called loadAllMembers.
Fix the former problem by adding a 'has destructor' bit to ClassDecl so we can track whether the implicit destructor needs to be added without querying its members. Fix the latter by making IterableDeclContext::addMember not call loadAllMembers, and making loadAllMembers not barf when it sees existing members in the context.
Together with Jordan and JoeP's changes, this makes many interpreter tests now compile 3-20x faster.
Swift SVN r17562
This basically just means "it's a CF class" for now,
but you could imagine applying this to all sorts of
class-like types from peer runtimes that we can't
support all possible language features for.
There are quite a few language features that require
fairly deep object-model integration to implement,
like subclassing and adding polymorphic methods.
Some of those features, like final classes, are useful
to generally support as attributes, but most of
them aren't. At least in the short term, it makes
sense to have a big hammer we can hit things with.
Swift SVN r17428
Subscript declarations were still encoding the names of index
variables in the subscript type, which unintentionally made them
keyword arguments. Bring subscript declarations into the modern day,
using compound names to encode the subscript argument names, which
provides consistency for the keyword-argument world
<rdar://problem/14462349>. Note that arguments in subscripts default
to not being keyword arguments, which seems like the right default.
We now get keyword arguments for subscripts, so one can overload
subscripts on the names of the indices, and distinguish at the call
site. Under -strict-keyword-arguments, we require strictness here as well.
The IRGen/IDE/SILGen test updates are because the mangling of common
subscripts changed from accidentally having keyword arguments to not
having keyword arguments.
Swift SVN r17393
This is needed for unit tests to import app modules, but could also be used
to get rid of the "/32" used for the standard libraries.
This is the rest of <rdar://problem/16776466>
Swift SVN r17177
When deserializing, the serialized sil loader attempts to first lookup
from its SILModule the witness table to attempt to grab a witness table
declaration. Before this patch if the SILModule could not find it, it
would attempt to deserialize it. In certain edge cases this would cause
us to attempt to deserialize a function definition which violates the
invariant that that should never happen.
This patch adds an argument to SILModule::lookUpWitnessTable that
enables you to turn off the lazy deserialization behavior. The default
argument gives the current behavior which should be used everywhere
except for the deserializer.
Swift SVN r16740
An unsafe cast from a base to a derived class isn't really all that different from one from Builtin.NativeObject to an arbitrary class, so relax this pair of instructions to allow an arbitrary bitcast. This only combines the instructions; it doesn't attempt to simplify any codegen that was emitting round-trip casts before yet.
Swift SVN r16736
This allows the payload for a loadable enum to be unsafely projected without branching, enabling more enum optimizations when switch branches can be culled or when indirect enum code can be promoted.
Swift SVN r16729
This was part of the original weak design that
there was never any particular reason to rush the
implementation for. It's convenient to do this now
so that we can use it to implement Unmanaged<T> for
importing CF types.
Swift SVN r16693
The implied semantics are:
- side-effects can occur any time before the first invocation.
- all calls to the same global_init function have the same side-effects.
- any operation that may observe the initializer's side-effects must be
preceded by a call to the initializer.
This is currently true if the function is an addressor that was lazily
generated from a global variable access. Note that the initialization
function itself does not need this attribute. It is private and only
called within the addressor.
Swift SVN r16683
Give us a way to formally represent autoreleases in SIL separate from autoreleased returns, allowing us to lifetime-extend inner pointer parameters the lazy way and hopefully clean up some asmname hacks in the stdlib implementation too.
Swift SVN r16632
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
Use this node to capture the argument name and its source location in
the AST. We're only building these in one place at the moment; the
rest will be updated soon.
Swift SVN r16581
The use of ASTContext-allocated arrays to store the members of nominal
type declarations and the extensions thereof is an
abomination. Instead, introduce the notion of an "iterable"
declaration context, which keeps track of the declarations within that
context (stored as a singly-linked list) and allows iteration over
them. When a member is added, it will also make sure that the member
goes into the lookup table for its context immediately.
This eliminates a ton of wasted memory when we have to reallocate the
members arrays for types and extensions, and moves us toward a much
more sane model. The only functionality change here is that the Clang
importer no longer puts subscript declarations into the wrong class,
nor does it nested a C struct within another C struct.
Swift SVN r16572
NFC. DeclRange is a range over DeclIterators, and is used rather than
ArrayRef<Decl*> to retrieve the members of a nominal type declaration
or extension thereof. The intent is to change the representation of
DeclRange next.
Swift SVN r16571
Before this fix, we can't deserialize any SILFunction with generic outer
parameters.
We do not have the decl associated with the generic parameter list at SIL level,
so instead of using a nullptr decl, we serialize the outer generic parameters
directly.
rdar://16630493
Swift SVN r16562
The on-disk hashtable is moving from clang to llvm. This updates some
consumers for the new path and namespace. I've also shortened the
make_range(data_begin(), data_end()) calls on the hash table to just
use data().
Swift SVN r16537
Factory initializers express an initializer that produces an object of
the given type, but is not inherited and not designated. Although they
have a syntactic form for presentation purposes (-> ClassName), there
is no way to specify or implement them within Swift. Rather, factory
initializers are created when importing an Objective-C factory method
that returns the class type rather than instancetype.
Swift SVN r16528
Convenience factory initializers are convenience initializers produced
by importing an Objective-C factory method as a convenience
initializer. The distinction is currently only used to eliminate the
awful layering violation I recently introduced in name lookup, which
was consulting Clang AST nodes directly. It will also be useful in
SILGen.
Swift SVN r16527
Introduce CtorInitializerKind to describe the kind of an enum, rather
than a bool, to make way for more initializer kinds in the future.
Swift SVN r16525
