Previously, serialization of a single source file only includes decls that
are within the SourceFile context. However, new top-level decls can be
added in order to derive protocol conformances; these decls need to be
serialized /somewhere/. Add the concept of decls "forced" to be serialized
along with the decls within the primary SourceFile context, and then mark
all derived top-level decls as "forced" if they come from a decl in the
primary source file.
Possibly a fix for <rdar://problem/16254101>, which crashes nearby.
Swift SVN r14817
Before, we would hit one of the error conditions before updating the path
trace, which was misleading at best.
No functionality change.
Swift SVN r14815
The standard library likes to have default definitions for associated types,
which is good. Often the /choice/ of default type, however, is a type that
(indirectly) conforms to the very protocol containing the associated type.
Rather than try to make sure everything is present all at once, just delay
the deserialization of the default definition until it's actually requested.
This does swell the size of AssociatedTypeDecl by two words. I've filed
<rdar://problem/16266669> to remind myself to try to reduce this.
Part of <rdar://problem/16257259>
Swift SVN r14809
Make the name lookup interfaces all take DeclNames instead of identifiers, and update the lookup caches of the various file units to index their members by both compound name and simple name. Serialized modules are keyed by identifiers, so as a transitional hack, do simple name lookup then filter the results by compound name.
Swift SVN r14768
Add __FUNCTION__ to the repertoire of magic source-location-identifying tokens. Inside a function, it gives the function name; inside a property accessor, it gives the property name; inside special members like 'init', 'subscript', and 'deinit', it gives the keyword name, and at top level, it gives the module name. As a bit of future-proofing, stringify the full DeclName, even though we only ever give declarations simple names currently.
Swift SVN r14710
to the archetypes of their generic parameter declarations.
This was a major inconsistency that was causing a lot of
problems with deserialized generic functions in the presence
of chained module files. In particular, what would happen is
that all the deserialized uses of the archetype would be
mapped to a freshly-created archetype, but the GenericParamList
would refer to GenericTypeParamDecls deserialized from
(potentially) a different ModuleFile and therefore using a
different archetype (since the deserializer assumes that
different modules never share archetypes).
The fix relies on processing a generic parameter list before
any references to the archetypes. Unfortunately, we have
bogus references to archetypes in substitution lists scattered
everywhere in SIL and the AST. I've introduced a really
gross hack where we allow archetypes to be created in that
way but just drop them (in favor of the parameter's archetype)
after processing the generic parameter list; this should
work as long as all the decontextualized references are
basically pointless, but like I said, it's gross, and I've
filed rdar://16240384 to clean it up.
Swift SVN r14694
If we got just the wrong chain of dependencies, we'd create two VarDecls
for the same variable. I'm not sure if any of the other decls have the
same problem, but better safe than sorry.
I couldn't think of a small test case for this, but it does fix the one
in the Radar.
<rdar://problem/16205936>
Swift SVN r14625
This fixes a bug where we were deserializing a function with a call to a shared
linkage function. The shared linkage function was never deserialized causing an
assertion to fire due to shared linkage functions always needing a definition.
I am planning on implementing lazy deserialization of vtable functions.
Swift SVN r14581
alloc_ref_dynamic allocates an instance of a class type based on the
value in its metatype operand. Start emitting these instructions for
the allocating constructor of a complete object initializer (not yet
tested) and for the allocating constructor synthesized for an imported
Objective-C init method.
Still missing:
- IRGen still does the same thing as alloc_ref right now. That
change will follow.
- There are devirtualization opportunities when we know the value of
the metatype that would turn an alloc_ref_dynamic into an alloc_ref;
I'm not planning to do this optimization.
Swift SVN r14560
It's not forming the metatype for the protocol type (exists t: P. t).metatype, it's forming the existential of a metatype of a conforming type, exists t: P. (t.metatype).
Swift SVN r14520
Having one instruction to get the dynamic metatype of a (non-existential) value makes more sense from a generic specialization standpoint and should stave off inevitable crashers when archetype_metatypes get specialized. protocol_metatype remains separate because metatype existentials are more interesting.
Swift SVN r14499
We were wantonly applying 'upcast' to archetypes in some cases, and really, that's OK, since these instructions do the same thing (and generic specialization could turn archetype_ref_to_super into upcast). Make everyone's life easier by folding archetype_to_super into upcast. Fixes <rdar://problem/16192324>.
Swift SVN r14496
The 'override' attribute indicates that the given declaration, which
may be a method, property, or subscript, overrides a declaration in
its superclass. Per today's discussion, the 'override' attribute must
be present if and only if the corresponding declaration overrides a
declaration in its superclass.
This implements most of <rdar://problem/14798539>. There's still more
work to do to on property and subscript overrides.
Swift SVN r14388
With this commit, we can deserialize the stdlib. Still running into
issues related to linking that requires a consultation with John. That
will come in a later commit.
Swift SVN r14365
Swift can now find modules inside framework bundles matching this layout:
Foo.framework/
Foo.swiftmodule/
ARCH.swiftmodule
Currently, ARCH is the architecture name used by build configurations (#if),
but this was more done out of convenience than anything else (there's
currently no access to the current target from the ASTContext). We'll need
to revisit this if/when we decide to support architecture subtypes (armv7s
vs. armv7 vs. arm), at which point we'll also have to deal with fallback
architectures.
Framework search paths are specified using -F. Like bare import paths, there
are currently no "built-in framework search paths".
The master plan for Swift frameworks is in <rdar://problem/16062602>.
<rdar://problem/16155907>
Swift SVN r14363
The default (F_None) used to mean F_Text, now it is F_Binary, which is arguably
a better default. It only matters on Windows anyway, so just use F_None (to
mean binary mode) everywhere to allow Swift to be compled with older LLVM as
well as current ToT.
Swift SVN r14312
These changes add support for build and target configurations in the compiler.
Build and target configurations, combined with the use of #if/#else/#endif allow
for conditional compilation within declaration and statement contexts.
Build configurations can be passed into the compiler via the new '-D' flag, or
set within the LangOptions class. Target configurations are implicit, and
currently only "os" and "arch" are supported.
Swift SVN r14305
lowered field type of a ref_element_addr's parent projection, rather than using
the unlowered siltype generated via creating a SILType from the field's
vardecl.
Swift SVN r14294
We should also remove it from IRGen's Explosion API; IRGen
should always use maximal explosion, and SILGen will tell us
whether or not we need to put that in memory somewhere.
But that can be a later commit.
Swift SVN r14242
