This will help with ensuring that we do not create multiple witness
table "definitions" one of which is null. That situtation yields an
IRGen assertion to be hit since the external declaration (in the guise
of a definition) has a different type from the actual deserialized
definition.
Swift SVN r14999
Now that the standard library depends on Clang headers, every single tool
needs to specifically avoid using the default module cache when
SWIFT_MODULE_CACHE_PATH is set.
<rdar://problem/16294222>
Swift SVN r14937
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
The standard library is about to start using some C/Objective-C
declarations internally, which means every tool needs to be import
C/Objective-C. (Don't worry, they're keeping it small.)
Apologies for your link times.
(The NullClangImporter is dead; I'll remove it next week.)
Swift SVN r14821
Fix a phase ordering problem: SILGen of a noreturn function doesn't drop an unreachable after the function,
and doing so is problematic for various reasons (all expressions would have to handle their insertion point
vaporizing, and would have to emit unreachable code diagnostics). Instead, run a simple pass that folds
noreturn calls and diagnoses unreachable code, and do it before DI. This prevents DI from seeing false
paths, and rejecting what seems like invalid code.
Swift SVN r14711
This patch fixes a number of issues:
1. We were not linking libswiftOptimizeARC.a into SwiftARCPasses.dylib.
2. If you did perform that linking since libswiftOptimizeARC.a had a bunch of
llvm statically linked into it, opt would see multiple instances of certain
options causing it to error out.
Now we don't statically link in a ton of LLVM into libswiftOptimizeARC.a and
properly link libswiftOptimizeARC.a into SwiftARCPasses.dylib.
Swift SVN r14557
This is necessary to not link in a duplicate copy of LLVMSupport. This is
the same interface as LLVM's example modules and Clang's sample plug-ins.
Fariborz, if this breaks your Xcode setup again, please let me know and I'll
come take a look. (The Clang targets work fine for me in Xcode.)
Swift SVN r14547
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
pass and instead was calling the verifier after adding every pass to the pass
manager (i.e. just wasting cpu time). Instead enable sil-verify-all by default
to get the same effect.
Swift SVN r14213
Currently supports dumping decls and SILModules from the standard library only.
This restriction is good enough for my purposes of verification of the
deserialization of SIL and allows me to ignore the complexity of having multiple
source files (which not being the stdlib implies most of the time).
Swift SVN r14187
...because doing so might cause more Clang types to be deserialized, which
before led to trying to SILGen un-type-checked auto-generated helpers.
Swift SVN r14017
As part of this, have the standard library target be responsible for
symlinking Clang's headers into the resource directory, instead of the
compiler target. This makes sure the headers show up in all copies of
the build directory.
This brings our iOS testing closer to what Xcode will do, which will
hopefully avoid issues like <rdar://problem/16052579>.
Swift SVN r13890
This is equivalent to Clang's -fresource-dir; it provides the location of
compiler modules and libraries.
No end-user-visible changes, but the iOS build will no longer have to use
-I to build and test its own standard libraries.
Swift SVN r13888
swift_old will stick around for another week at least for A/B testing.
After that, "swift -frontend" will handle the low-level stuff, and
"swift -force-single-frontend-invocation" will do a high-level build
in the style of swift_old.
Swift SVN r13804
