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
OnDiskIterableChainedHashTable interface introduced in CFE 206189.
Thanks to Justin for guiding me through this!
The test-failures I was worried about after I originally committed this
turned out to be unrelated.
Swift SVN r16340
Swift will use the basename + argument names formulation for
names. Update the DeclName interfaces, printing, and __FUNCTION__ to
use the method syntax.
We'll still need to rework the "x.foo:bar:wibble:" syntax; that will
come (significantly) later.
Swift SVN r15763
In a framework containing both Clang headers and a Swift module, the Swift
module gets picked up first, but then automatically imports (and re-exports)
the Clang module as well.
One interesting case here is that it's possible for the Clang side to add
categories to a class declared in Swift. In order to support this, the
Clang importer can now find extensions for Swift classes marked @objc.
(I couldn't think of a way to test this separately; the previous commit
was supposed to do that, but worked without this change.)
<rdar://problem/16295937>
Swift SVN r15084
The driver infers the filename from the module file by replacing the extension,
and passes the explicit path to the swiftdoc file to the frontend. But there
is no option in the driver to control emission of swiftdoc (it is always
emitted, and name is always inferred from the swiftmodule name).
The swiftdoc file consists of a single table that maps USRs to {brief comment,
raw comment}. In order to look up a comment for decl we generate the USR
first. We hope that the performance hit will not be that bad, because most
declarations come from Clang. The advantage of this design is that the
swiftdoc file is not locked to the swiftmodule file, and can be updated,
replaced, and even localized.
Swift SVN r14914
This won't ever happen naturally, but by either messing with the module file
or asking the compiler to load something that isn't a module at all we could
end up hitting the assert.
<rdar://problem/16274875>
Swift SVN r14902
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
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
From now on, /any/ changes to SIL or AST serialization must increment
VERSION_MINOR in ModuleFormat.h.
The original intent of VERSION_MAJOR/VERSION_MINOR was that VERSION_MAJOR
would only increment when backwards-incompatible changes are introduced,
and VERSION_MINOR merely indicates whether to expect additional information.
However, the module infrastructure currently isn't forgiving enough to accept
even backwards-compatible changes to the record schemas, and the SIL
serialization design might not be compatible with that at all.
So for now, treat any version number 0.x as incompatible with any other 0.y.
We can bump to 1 when we hit stability.
<rdar://problem/15494343>
Swift SVN r13841
This necessitated adding a new function to validate a serialized AST, so
that we can get the same information that used to be extracted from the
section header.
For now, we'll continue accepting the wrapped ASTs as well, since we
haven't changed the existing debug info generator.
Swift SVN r12922
We don't currently use this for anything, but if we have the module name
available and easy to access in the bitstream, we can drop the wrapper
around the serialized AST that's put into the binary itself for use by LLDB.
Swift SVN r12921
We don't currently use this for anything, but if we have the module name
available and easy to access in the bitstream, we can drop the wrapper
around the serialized AST that's put into the binary itself for use by LLDB.
Swift SVN r12919
The only reason to do this was in case an extension adopted a compiler-known
protocol, but that has long ben taken care of by
ModuleFile::loadDeclsConformingTo.
Swift SVN r11224
There shouldn't ever be a reason to do this: if a conversion function is
ever selected by the type-checker, it's because the type the conversion
lives on was suggested by another constraint, which means we can do a
normal lookup for the conversion function.
This is actually the only thing being eagerly deserialized, so remove the
notion of eager deserialization altogether.
Swift SVN r11220
Since we don't have soft-failure yet from deserialization, it's helpful to
at least know where to start looking when something crashes. There are some
rough edges here but it should be much better than nothing.
This also pulls the list of record nodes out into a separate file, so that
we can avoid repeating it.
Example crash:
1. While reading from ./CTypes.swiftmodule
2. While deserializing 'CBool' (StructDecl)
3. While deserializing decl #26 (XREF)
4. Cross-reference to 'LogicValue' in swift
(don't worry, this is an example where I'm tweaking things)
<rdar://problem/14838332>
Swift SVN r11057
Each loaded file gets added to the main module, rather than being a standalone
separate module. In theory, this will be used to assemble several partial
ASTs into a complete module. In practice, there's still a ways to go...but
this can already round-trip a single module file.
This also factors out the FileUnit-creating part of SerializedModuleLoader,
which should help clients like SourceKit that don't need to search for a
swiftmodule file associated with a particular import.
Swift SVN r10952
Part of the FileUnit restructuring. A serialized module is now represented as
a TranslationUnit containing a single SerializedASTFile.
As part of this change, the FileUnit interface has been made virtual, rather
than switching on the Kind in every accessor. We think the operations
performed on files are sufficiently high-level that this shouldn't affect us.
A nice side effect of all this is that we now properly model the visibility
of modules imported into source files. Previously, we would always consider
the top-level imports of all files within a target, whether re-exported or
not.
We may still end up wanting to distinguish properties of a complete Swift
module file from a partial AST file, but we can do that within
SerializedModuleLoader.
Swift SVN r10832
Previously we would cache the results of operator lookup whether or not the
operator we found came from an imported module. Since different source files
can have different imports, it's not correct to automatically share operators
from imported modules with all files in the translation unit.
This still isn't fully correct; the current logic prefers operators from
local imports over operators implicitly available from other source files.
Swift SVN r9683
Semantic context describes the origin of the declaration and serves the same
purpose as opaque numeric "priority" in Clang -- to determine the most likely
completion.
This is the initial implementation. There are a few opportunities to bump the
priority of a certain decl by giving it SemanticContextKind::ExprSpecific
context that are not implemented yet.
Swift SVN r9052
SerializedSILLoader to hold a list of SIL deserializers.
Also add an intial implementation of a linking pass that is run right after
SILGen to link the declaration of SILFunction to the actual definition in
the serialized module.
We add two blocks to the serialized module: a sil index block that
maps identifier to a function ID and also holds a list of function offsets,
and a sil block for the actual SILFunctions. We can probably use subblock
instead of two top-level blocks.
The serialization/de-serialization of the function hash table and the function
offsets are implemented. But we are missing handling of types (see FIXME in
the code).
ModuleFile::Serialized is made public to be used by SIL deserializer, as well
as ModuleFile::getType.
The SIL deserializer holds a pointer to the ModuleFile, it gets the sil cursor
and the sil index cursor from the ModuleFile. The other option is for SIL
deserializer to find the start of the two sil blocks within itself, thus having
less coupling with ModuleFile.
No testing case yet because we are missing handling of types.
Swift SVN r8206
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
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
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
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
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
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
Break cycles agressively when we find circular class inheritance. The
stronger AST invariants prevent us from having to check for loops
everywhere in the front end.
Swift SVN r7325
