and remove DeclContext base class from FuncDecl, ConstructorDecl and
DestructorDecl
This decreases the number of DeclContexts to 7 and allows us to apply
alignas(8) to DeclContext.
Swift SVN r8186
Now that we're actually serializing this explicitly (because it's needed
in the constructor), we can use it to check whether we actually serialized
the right number of patterns. This also paves the way for a minor
optimization: not serializing two sets of parameters when not dealing with
a selector-style declaration.
Swift SVN r8098
few SIL instructions types.
This will be tested when we have a SIL deserializer. Testing cases covering
each implemented SIL instruction will be added.
Swift SVN r8094
Fixes two bugs in Clang importer and deserialization code that were found by
the verifier:
(1) FuncExprs were created with a null FuncDecl
(2) BoundGenericType that was created by Clang importer for UnsafePtr<> and
other magic types did not have substitutions.
Swift SVN r8073
ConstructorDecl::getBody() and DestructorDecl::getBody() return 'BraceStmt *'.
After changing the AST representation for functions, FuncDecl::getBody() will
return 'BraceStmt *' and FuncDecl::getFuncExpr() will be gone.
Swift SVN r8050
getDisplayDecls() was introduced for ":print_module" and works slightly differently, e.g.
it will return the decls from a shadowed clang module, since we want to display them.
Swift SVN r7909
functions should be serialized.
Transparent is added as a 1-bit field. In SILGen, we set SILFunction's
transparent attribute according to the attribute of the ValueDecl.
Swift SVN r7882
Add SerializeSIL.cpp for basic implementation of a SIL serializer.
serialize, serializeToStream, Serializer::writeToStream, and
Serializer::writeTranslationUnit all take an additional SILModule to pass it
to Serializer::writeSILFunctions.
Serializer::writeSILFunctions goes through all SILFunctions in a SILModule, and
serializes all SILFunctions that are transparent.
Swift SVN r7875
Per discussion with Doug, there's no reason why this should not work:
class Outer {
class Inner {
func extract() { ... }
}
}
var obj : DynamicLookup = ...
obj.extract!()
Swift SVN r7763
As a bring-up hack, the module serializer would write a special record,
FALL_BACK_TO_TRANSLATION_UNIT, if it encountered something it didn't know
how to serialize. This then directed the deserializer to ignore the
contents of the module file and instead reload the original source file.
Now that we can serialize pretty much everything*, though, we don't need
this, and instead we'd rather know where the serialization coverage has
gaps (by asserting).
Swift SVN r7752
Add tools/lldb-moduleimport-test, which simulates LLDB importing modules
from the __apple_ast section in Mach-O files and use it to regression-test
the new API.
Swift SVN r7709
When performing member lookup into an existential that involves the
DynamicLookup protocol, look into all classes and protocols for that
member. References to anything found via this lookup mechanism are
returned as instances of Optional.
This introduces the basic lookup mechanics into the type
checker. There are still numerous issues to work through:
- Subscripting isn't supported yet
- There's no SILGen or IRGen support
- The ASTs probably aren't good enough for the above anyway
- References to generics will be broken
- Ambiguity resolution or non-resolution
Thanks to Jordan for the patch wiring up DynamicLookup.
Swift SVN r7689
Each nested archetype X.Y corresponds to an associated type named 'Y'
within one of the protocols to which X conforms. Record the associated
type within the archetype itself. When performing type substitutions,
use that associated type to extract the corresponding type witness
rather than looking for the type itself. This is technically more
correct (since we used the type witness for type checking), and a step
toward pulling type substitutions into the AST.
Swift SVN r7624
This isn't very efficient: it scans every decl in the Clang TU (forcing
deserialization) and filters based on the decl's enclosing module.
Moreover, since getClangModuleForDecl() currently only handles top-level
modules, all submodules get implicitly added to the top-level module...
and will /not/ match an explicit submodule request.
(This is probably close to the behavior we actually want: include decls that
are from modules that are (a) submodules and (b) re-exported by the top-level
module. We do want that extra check, though, and we would want to find things
specifically by submodule.)
Swift SVN r7602
This is basically the same as doing a :print_decl on every decl in the module,
except that it does not print extensions that come from other modules, and
/does/ print extensions and operators that come from this module.
Does not yet work for Clang modules or the Builtin module.
Swift SVN r7601
We previously relied on the type checker to fill in the implementation
types (swift.Slice<T> and swift.Optional<T>, respectively), which
limited our ability to perform type transformations in the AST. Now,
the AST knows how to form these implementation types on demand.
Swift SVN r7587
In Swift, a module is expected to know which libraries it needs, rather than
having this specified by an external module map. While we haven't quite
designed this yet (frameworks get this for free in Clang, for example),
we can at least provide a simple option for the common case of a module
associated with a single library.
This will probably change in the future, so I left in the more general
deserialization code I was working on before simplifying the use case.
A loaded module can in theory specify any arbitrary frameworks or libraries
as dependencies, not just a single dylib.
Swift SVN r7583
...instead of just those that are re-exported. This will be used for
autolinking (and probably few other places).
As part of this, we get two name changes:
(1) Module::getReexportedModules -> getImportedModules
(2) TranslationUnit::getImportedModules -> getImports
The latter doesn't just get modules-plus-access-paths; it also includes
whether or not the import is re-exported. Mainly, though, it just didn't
seem like a good idea to overload this name when the two functions aren't
really related.
No tests yet, will come with autolinking.
Swift SVN r7487
This breaks the type-canonicalization link between a generic parameter
type and the archetype to which it maps. Generic type parameter types
are now separate entities (that can eventually be canonicalized) from
archetypes (rather than just being sugar).
Most of the front end still traffics in archetypes. As a step away
from this, allow us to type-check the generic parameter list's types
prior to wiring the generic type parameter declarations to archetypes,
using the new "dependent" member type to describe assocaited
types. The archetype builder understands dependent member types and
uses them to map down to associated types when building archetypes.
Once we have assigned archetypes, we revert the dependent identifier
types within the generic parameter list to an un-type-checked state
and do the type checking again in the presence of archetypes, so that
nothing beyond the generic-parameter-list checking code has to deal
with dependent types. We'll creep support out to other dependent types
elsewhere over time.
Swift SVN r7462
Previously, we were creating the type corresponding to
class/struct/union declarations as part of creating the declaration
node, which happens at parse time. The main problem with this (at the
moment) occurs with nested nominal types, where we'd end up with the
wrong "parent" type when the type was nested inside an extension
(because the extension hadn't been resolved at the time we accessed
the parent's type). Amusingly, only code completion observed this,
because the canonical type system hid the problem. The churn in the
code-completion tests come from the fact that we now have the proper
declared type for class/struct/union declarations within extensions.
Take a step toward order-independent type checking by setting the type
of a class/struct/union declaration in type checking when we either
find the declaration (e.g., due to name lookup) or walk to the
declaration (in our walk of the whole translation unit to type-check
it), extending the existing TypeChecker::validateTypeDecl() entry
point and adding a few more callers.
The removeShadowedDecls() hack is awful; this needs to move out to the
callers, which should be abstracted better in the type checker anyway.
Incremental, non-obvious step toward fixing the representation of
polymorphic function types. This yak has a *lot* of hair.
Swift SVN r7444
proposal.
When compiling with debug info, build a swiftmodule that contains all the
type decls referenced by DWARF and emit it into a special __apple_swiftast
section in the .o file.
Swift SVN r7398
Make the functions support a wider range of builtins and store types to make
it possible.
This is an optimization - the cached ID will be used for builtin identification,
instead of retrieval of the string name and using it as the key.
Swift SVN r7390
Another baby step toward a proper canonical form for polymorphic
function types: generic parameters will eventually be uniquable by
their depth and index.
Swift SVN r7380
Previously, TypeAliasDecl was used for typealiases, generic
parameters, and assocaited types, which is hideous and the source of
much confusion. Factor the latter two out into their own decl nodes,
with a common abstract base for "type parameters", and push these
nodes throughout the frontend.
No real functionality change, but this is a step toward uniquing
polymorphic types, among other things.
Swift SVN r7345
This separates the concerns of "deserialization the AST structures" from
"reading and accessing a module file".
No functionality change.
Swift SVN r7338
This will be used to resolve properties and method calls on objects with
dynamic-lookup ("id") type. For now, this is tested in swift-ide-test
by using the -dynamic-lookup-completion option and providing a
-code-completion-token value.
Caveats/TODOs:
- As before, since we're using the global method pool, this isn't scoped by
module. We could do a per-module filter, but I don't know if that will
actually buy us much.
- Again, Clang's method pool does not include methods from protocols.
- Lookup by selector name cannot find properties with a customized getter
name. <rdar://problem/14776565>
- The Clang-side method pool is keyed by selector, but Swift wants to look
things up by method name, which maps to the first selector piece, so we
end up having to do a scan of all the selectors in the pool.
Swift SVN r7330
