Rather than automatically re-exporting or not re-exporting every import in
a TranslationUnit, we'll eventually want to control which imports are local
(most of them) and which imports are shared with eventual module loaders.
It's probably not worth implementing this for TranslationUnit, but
LoadedModule can certainly do something here.
Currently, a LoadedModule is even more permissive than a TranslationUnit:
all imports are re-exported. We can lock down on this once we have a
re-export syntax.
Swift SVN r6523
...and use it for shadowed modules (e.g. the Clang module "Foundation"
referenced by the Swift module "Foundation"), so that we can actually
find "NSString" when building AppKit.
Additionally, record shadowed modules as dependencies, so that they can
be loaded when the adapter module is loaded.
Swift SVN r6522
This unfortunately duplicates the hack of directly referencing the Clang
module loader if a cross-reference points to the current module; ideally
we'd have some kind of module chain, but I'd settle for a refactoring of
the code to share with NameBinding.
Additionally, Clang nodes are not actually validated to be from the right
module, which could be problematic for extensions or any case of actual
name collision.
Swift SVN r6519
If a protocol requirement is satisfied by a generic method, we'll need to save the substitutions necessary to call that method from the witness thunk. This patch adds the spot in the ProtocolConformance::Mapping to save the substitutions; for now, always leave it empty and update the code for the type change.
Swift SVN r6399
- Add the attribute to AnyFunctionType::ExtInfo.
- Propagate the attributes from DeclAttributes to AnyFunctionType for
FuncDecls in TypeCheckDecl.cpp.
- Make sure the new attribute is serialized.
The main missing pieces are checking the applicability of the type attributes
on the FuncDecl and teaching typechecker about conversions on types with
noreturn.
Swift SVN r6359
Elements of a tuple type now know if there is a default argument, and
what kind of default argument it is (callee side, __FILE__, __LINE__,
__COLUMN__), but they don't have an actual expression. There are a
number of cleanups this enables that will follow.
Note that the serialization support is as-yet-untested.
Swift SVN r6351
Generic parameters are implemented using specially-tagged TypeAliasDecls.
Unlike normal ValueDecls, their names are not resilient, and so cross-
module references shouldn't refer to them by name. Instead, use an index
into the generic parameter list of their context.
Since generic parameters can appear within extensions, this new kind isn't
mutually exclusive with the just-introduced ExtensionValue. Change that to
be a separate flag that applies to both Values and GenericParameters.
Swift SVN r6304
Previously, cross-references used a simple access path to refer to values
in other modules, but extensions have no name. They also accidentally
picked up values in extensions anyway, because lookupDirect includes
members in extensions. Now, we filter out values that don't come from
the referenced module, which may not be the same module the base type
comes from.
Swift SVN r6301
Teach TuplePatternElt to keep track of the kind of the default
argument: none, normal (provided by calling into the appropriate
callee generator), __FILE__, __LINE__, or __COLUMN__. For the latter
three cases, the type checker forms the appropriate argument as part
of the call.
The actual default argument expression will only be held in the tuple
pattern element when we've parsed it; it won't be serialized or
deserialized, because only the defining module cares. This is a step
toward eliminate the initialization expression from tuple types.
The extension to TupleShuffleExpr is a hack, which will also be
replicated in ScalarToTupleExpr, until we finally rework the
representation of TupleShuffleExpr (<rdar://problem/12340004>).
Swift SVN r6299
The semantics of varargs (only for the last element) make it more appropriate as a property of the TuplePattern.
Also free the Parser from needing to construct synthetic types (ArraySlice for type of vararg element) to
accommodate the TypeChecker and move the logic to the TypeChecker. This will be more beneficial when the parser stops
creating types in general.
Swift SVN r6271
As long as we don't create an entity twice, it's actually okay to be
re-entrant. This makes it simpler to deserialize members -- trying to
do so will deserialize the parent instead, which will then initialize
each of the members including the one that was asked for.
Swift SVN r6228
Deserializing a nominal decl often ends up referring to the nominal's type,
so if we're /already/ serializing the type, we should finish that as soon
as we have a decl. Accomplish this by adding a callback that is called
right after a nominal decl is recorded in the module's decl table, so that
the type can be immediately recorded as well.
Swift SVN r6227
Give oneof bodies syntax consistent with other NominalTypes. Give oneof elements first-class declaration syntax using the 'case' introducer, as suggested by Jordan. Oneofs can contain 'case' decls, functions, properties, and constructors, but not physical ivars. Non-oneof scopes cannot contain 'case' decls. Add some QoI to the oneof 'case' parser to also parse and complain about things that resemble switch 'case' labels inside decl contexts.
Swift SVN r6211
I had previously thought these didn't appear in public decls, but they're
used when you extend a generic class without generic arguments.
Swift SVN r6187
Currently, we are eagerly deserializing extensions. This probably isn't
what we want to do in the long run, but until lookup settles down a bit
it's not worth optimizing.
Swift SVN r6186
Take advantage of the fact that a function can never be both a conversion
method and an assignment operator to pack both flags into the same bit in
the serialized record.
Swift SVN r6185
For consistency purposes, VarDecls in the subscript pattern now have the
enclosing nominal as their decl context, rather than no decl context at all.
Swift SVN r6177
Turns out we actually have to serialize the name of an archetype, because
it may be different from the declaration in a context where it has been
unified with another archetype. Found on attempting to emit a module for
the standard library.
(This is actually the commit that uses the two-container for_each
introduced in the last commit.)
Swift SVN r6172
These still need to be serialized, because they are one-to-one with the
type's protocol list, but don't actually require any data. Found on
attempting to emit a module for the standard library.
Most of the churn here is moving Interleave.h to a more general STLExtras.h.
Swift SVN r6167
The way llvm::BitstreamCursor works is that reading an end-of-block
code will pop the current block off the stack, along with all its
record abbreviation codes. This means we’d no longer know how to
read any records. Fix this by telling the cursor not to auto-pop blocks
any time we’re doing a tentative read.
Swift SVN r6135
Since accessor FuncDecl have a backreference to the VarDecl they are
attached to, we were getting re-entrant deserialization issues. Fix
this by just not serializing the backreference and relying on the
property being deserialized first.
Swift SVN r6134
Classes are exactly like structs except that they may have a base class.
However, this type will show up in the inheritance list. That means we
don't actually need to serialize it twice; we can just grab the base class
from the inheritance list.
Swift SVN r6133
...in a quest for completeness. ArrayTypes don't actually work yet
(single-dimensional arrays are typed as slices), but when they do the test
that is currently XFAIL'd should start passing.
With this, all non-transient types can now be serialized and deserialized.
Swift SVN r6101
This is the first time reaching the case where the module refers to a type
that also appears in the TU and tries to modify it. This shouldn't be a
problem for any of the other types we currently serialize besides
BoundGenericType and ArraySliceType because we either don't try to modify
them after creation or are guaranteed a new type object.
Swift SVN r6060
PolymorphicFunctionTypes are built on GenericParamLists, which are
owned by decls that introduce generic parameters. This made deserializing
them a pain, because they /cannot/ be recreated in isolation -- the decl
provides some context. Rather than try to come up with a very generic way
to serialize these, this patch just records the GenericParamList of every
decl, allowing the type to be serialized with a reference to the decl
instead of to the param list. Deserialization can then just pluck the list
back out of the decl.
According to Doug and Joe, PolymorphicFunctionType's due for a refresh
anyway, so this kind of hackery / kludgery is acceptable.
With this change, we can now handle generic structs and generic functions
inside generic structs.
Swift SVN r6032
