This is sort of two commits squashed into one: first, update
ReferencedNameTracker to record whether a name or type is non-private,
along with changing all clients to assume non-private; and second,
actually try to (conservatively) decide if a particular unqualified lookup can
be considered private.
What does "private" mean? That means that a dependency does not affect
"downstream" files. For example, if file A depends on B, and B depends on C,
then a change in C normally means A will get rebuilt. But if B's dependencies
on C are all private dependencies (e.g. lookups from within function bodies),
then A does not need to be rebuilt.
In practice there are several rules about when we can make this assumption,
and a few places where our current DeclContext model is not good enough to
distinguish private uses from non-private uses. In these cases we have to
be conservative and assume that the use is non-private (and thus that
downstream files will need to be rebuilt).
Part of rdar://problem/15353101
Swift SVN r23447
We need to do this mainly to figure out when extensions can affect this file.
This is part of the intra-module dependency tracking work to implement
incremental rebuilds.
Part of rdar://problem/15353101
Swift SVN r22927
Every name a file declares is something that another file in the same module
might depend on. The driver will need this information too to correctly
decide what files need to be rebuilt. This is part of the intra-module
dependency tracking work to implement incremental rebuilds.
This doesn't handle extensions yet, which are a bit trickier. Need to
figure out how to handle the interaction between extensions and typealiases.
Part of rdar://problem/15353101
Swift SVN r22926
This tracks top-level qualified and unqualified lookups in the primary
source file, meaning we see all top-level names used in the file. This
is part of the intra-module dependency tracking work that can enable
incremental rebuilds.
This doesn't quite cover all of a file's dependencies. In particular, it
misses cases involving extensions defined in terms of typealiases, and
it doesn't yet track operator lookups. The whole scheme is also very
dependent on being used to track file-level dependencies; if C is a subclass
of B and B is a subclass of A, C doesn't appear to depend on A. It only
works because changing A will mark B as dirty.
Part of rdar://problem/15353101
Swift SVN r22925
This is controlled by a new isWholeModule() attribute in SILModule.
It gives about 9% code size reduction on the benchmark executables.
For test-suite reasons it is currently not done for the stdlib.
Swift SVN r22491
Now the SILLinkage for functions and global variables is according to the swift visibility (private, internal or public).
In addition, the fact whether a function or global variable is considered as fragile, is kept in a separate flag at SIL level.
Previously the linkage was used for this (e.g. no inlining of less visible functions to more visible functions). But it had no effect,
because everything was public anyway.
For now this isFragile-flag is set for public transparent functions and for everything if a module is compiled with -sil-serialize-all,
i.e. for the stdlib.
For details see <rdar://problem/18201785> Set SILLinkage correctly and better handling of fragile functions.
The benefits of this change are:
*) Enable to eliminate unused private and internal functions
*) It should be possible now to use private in the stdlib
*) The symbol linkage is as one would expect (previously almost all symbols were public).
More details:
Specializations from fragile functions (e.g. from the stdlib) now get linkonce_odr,default
linkage instead of linkonce_odr,hidden, i.e. they have public visibility.
The reason is: if such a function is called from another fragile function (in the same module),
then it has to be visible from a third module, in case the fragile caller is inlined but not
the specialized function.
I had to update lots of test files, because many CHECK-LABEL lines include the linkage, which has changed.
The -sil-serialize-all option is now handled at SILGen and not at the Serializer.
This means that test files in sil format which are compiled with -sil-serialize-all
must have the [fragile] attribute set for all functions and globals.
The -disable-access-control option doesn't help anymore if the accessed module is not compiled
with -sil-serialize-all, because the linker will complain about unresolved symbols.
A final note: I tried to consider all the implications of this change, but it's not a low-risk change.
If you have any comments, please let me know.
Swift SVN r22215
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
We were already effectively doing this everywhere /except/ when building
the standard library (which used -O2), so just use the model we want going
forward.
Swift SVN r20455
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
The options themselves are now in swift::options (from swift::driver::options).
The soon-to-be-renamed createDriverOptTable() is now directly in the swift namespace.
Swift SVN r19825
This allows swiftFrontend to drop its dependency on swiftDriver, and could
someday allow us to move the integrated frontend's option parsing out of
swiftFrontend (which would allow other tools which use swiftFrontend to
exclude the option table entirely).
Swift SVN r19824
The upshot of this is that internal decls in an app target will be in the
generated header but internal decls in a framework target will not. This
is important since the generated header is part of a framework's public
interface. Users always have the option to add members via category to an
internal framework type they need to use from Objective-C, or to write the
@interface themselves if the entire type is missing. Only internal protocols
are left out by this.
The presence of the bridging header isn't a /perfect/ way to decide this,
but it's close enough. In an app target without a bridging header, it's
unlikely that there will be ObjC sources depending on the generated header.
Swift SVN r19763
In the frontend, only arguments after '--' will be passed as arguments
to the new process. Also, add the input filename as argv[0], to follow
the usual conventions.
Still to come is fixing swift -i from the driver.
Swift SVN r19690
...and just outright import the bridging header if that's what's needed.
This means we'll use @class and @protocol whenever we're just using a class
or protocol in a type, but still import the enclosing module when we need
the definition. We'll also fall back to the module (or bridging header) if
we need something /else/ from C: a struct, a typedef, whatever.
<rdar://problem/17183425>
Swift SVN r18795
Previously, the frontend detected that its output was being piped into the
driver and buffered, and decided that that wasn't a color-friendly output
stream. Now, the driver passes -color-diagnostics to the frontend to force
color output if the driver itself is in a color-output context.
<rdar://problem/16697713>
Swift SVN r18506
This performs very conservative dependency generation for each compile task
within a full compilation. Any source file, swiftmodule, or Objective-C
header file that is /touched/ gets added to the dependencies list, which
is written out on a per-input basis at the end of compilation.
This does /not/ handle dependencies for the aggregated swiftmodule, swiftdoc,
generated header, or linked binary. This is just the minimum needed to get
Xcode to recognize what needs to be rebuilt when a header or Swift source
file changes. We can revisit this later.
This finishes <rdar://problem/14899639> for now.
Swift SVN r18045
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
All serialization should go through serialize(). We don't currently support
serializing docs without serializing a module.
Also, tidy up how Serializer is used within Serialization.cpp.
Swift SVN r17637
Parse-only is a hot path; keep the semantics for it separate from normal parsing, otherwise it is very
easy to introduce something expensive without checking for Invocation.getParseOnly().
Also cleans up a bit CompilerInstance::performParse() as well.
Swift SVN r17596
This works, except when you launch it in -parse-stdlib mode, where running that expression fails, because Swift.Void wasn't pulled in, and that failure causes the REPL to quit
This patch passes down the -parse-stdlib flag to the REPL initialization code, such that it does not try to run any warm up code in -parse-stdlib mode
Swift SVN r15968
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 recommits r14446 with necessary changes.
The problem was that after my change SILGen was dumped before sil linking
occured. This change adds back in the code to ensure that sil linking occurs.
Swift SVN r14455
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
