This reverts commit dc98e17d84b991b6be8b8feb5e0d05aad24f52a4.
I believe this commit was causing test failures on:
IRGen/c_layout.sil
IRGen/existentials.sil
It also recreates the file lib/Serialization/ModuleFormat.h,
which really can't have been intended.
Swift SVN r23732
Adding explicit constructors to Clang-imported structs in the previous commits exposes a latent phase ordering issue between the Clang importer and SIL deserialization. Deserializing the standard library SIL ends up pulling in additional Clang decls which never get type-checked before we attempt to emit their code. Work around this by bringing back the "EagerDeserializedDecls" block in the serialization format, and adding any cross-referenced decls that get referenced in SILSerializeAll mode to it, so that we ensure they're available before SILGen. We also have to type-check external decls after doing so, since when only importing a module, we wouldn't do any type-checking at all otherwise.
Swift SVN r23728
Specifically, a qualified lookup can now be treated as:
- a known private dependency, which does not affect downstream files
- a known non-private dependency, which may affect downstream files
- a known non-dependency
- unknown, which means the compiler will try to infer whether it's a
private dependency from the context
This commit also includes some obvious uses of the new flags, but nothing
actually too interesting yet; there shouldn't be any observable behavior
change here in normal user code.
Swift SVN r23483
Include a mapping from Objective-C selectors to the @objc methods that
produce Objective-c methods with those selectors. Use this to lazily
populate the Objective-C method lookup tables in each class. This makes
@objc override checking work across Swift modules, which is part of
rdar://problem/18391046.
Note that we use a single, unified selector table, both because it is
simpler and because it makes global queries ("is there any method with
the given selector?") easier.
Swift SVN r23214
This included a test that failed on case-sensitive filesystems. Test fixed.
(Aside: Why not just have this fail with "no such module"? Why use a different
error? Because even if "import FOO" picks up a module named 'Foo', there may
actually be a module named 'FOO' on the system (in another folder), and we
should be able to find that. Fixing that is tracked by rdar://problem/18691936.)
rdar://problem/15632996 (again)
Swift SVN r22856
Due to case-insensitive filesystems, "import foundation" can result in the
overlay module for Foundation being loaded. Everything is confused later on
because the (wrong) module name is used in manglings, leading to all sorts
of issues.
This is not the right fix for the problem, because a user really is allowed
to have modules named "foundation" and "FOUNDATION" and "Foundation" coexisting
on their system. To do that we'll want to check the actual case of a
.framework bundle or .swiftmodule file on disk and make sure it matches before
even trying to load the file. But this is a good sanity check anyway.
rdar://problem/15632996
Swift SVN r22818
Like the Clang decls, this happens at the end of the type-checking, just as
a simple walk through the loaded decls of the loaded modules. This caught
all of the issues in this commit series and will hopefully keep us honest in
the future.
(By the way, we don't verify right when we return a deserialized decl for the
same reason we don't verify right when we return an imported decl: parts of
the decl may be delayed, and (a) we don't want to force things to be imported
or deserialized sooner than necessary, yet (b) we want to verify as much as
possible.)
rdar://problem/16968891
Swift SVN r22200
This is useful both for caching purposes and for comparison of discriminators
(something the debugger will need to do when looking up a particular decl).
No observable functionality change.
Swift SVN r21610
We currently mangle private declarations exactly like public declarations,
which means that private entities with the same name and same type will
have the same symbol even if defined in separate files.
This commit introduces a new mangling production, private-decl-name, which
includes a discriminator string to identify the file a decl came from.
Actually producing a unique string has not yet been implemented, nor
serialization, nor lookup using such a discriminator.
Part of rdar://problem/17632175.
Swift SVN r21598
Previously, we depended on whether or not a serialized module was located
within a framework bundle to consider whether or not it may have a "Clang
half". However, LLDB loads serialized modules from dSYM bundles. Rather
than try to figure out if such a module is "really" a framework, just track
whether the original module was built with -import-underlying-module. If so,
consider the underlying Clang module to be re-exported.
rdar://problem/18099523
Swift SVN r21544
Somewhere--and I forget where--either the LLVM bitcode system or the
OnDiskHashTable implementation depends on 32-bit alignment being preserved.
We had thought that only alignment /from the start of the stream/ mattered,
but it looks like the whole data section has to be 32-bit-aligned.
<rdar://problem/17814086>
Swift SVN r20599
If importing a Clang module fails, we should report that at the location of
the import statement. This doesn't do that fully because it isn't transitive
(if Swift module Foo imports Swift module Bar, which fails to import Clang
module Baz, we don't get an error in user source), but it's a step forward
for the simple cases.
Swift SVN r20575
"import func Darwin.C.math.hypot" will now work to just import "hypot".
(Since 'Darwin.C.math' is an implicit submodule of 'Darwin',
"import func Darwin.hypot" also works. That's okay.)
<rdar://problem/17272311>
Swift SVN r20356
it indirectly through another pointer from Decl, just embed DeclAttributes
directly into Decl and get rid of the "getMutableAttrs" nonsense.
Swift SVN r20216
We do this so that the swiftmodule file contains all info necessary to
reconstruct the AST for debugging purposes. If the swiftmodule file is copied
into a dSYM bundle, it can (in theory) be used to debug a built app months
later. The header is processed with -frewrite-includes so that it includes
any non-modular content; the user will not have to recreate their project
structure and header maps to reload the AST.
There is some extra complexity here: a target with a bridging header
(such as a unit test target) may depend on another target with a bridging
header (such as an app target). This is a rare case, but one we'd like to
still keep working. However, if both bridging headers import some common.h,
we have a problem, because -frewrite-includes will lose the once-ness
of #import. Therefore, we /also/ store the path, size, and mtime of a
bridging header in the swiftmodule, and prefer to use a regular parse from
the original file if it can be located and hasn't been changed.
<rdar://problem/17688408>
Swift SVN r20128
When a module built with -autolink-force-load is imported, add a reference
to a special symbol in the corresponding library so that ld is forced to
link it.
This means the library will be linked into the final binary even if no other
symbols are used (which happens for some of our overlays that just add
category methods to Objective-C classes).
Second part of <rdar://problem/16829587>
Swift SVN r17751
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
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
