This patch adds support for a builtin function assert_configuration that is
replaced by constant progpagation by an appropriate value dependent on a compile
time setting. This replacement can also be disabled when serializing sil for a
library.
Using this mechanism we implement assertions that can be disabled (or whose
behavior changes) depending on compile time build settings (Debug, Release,
DisableReplacement).
In the standard library we can now write one assert function that uses this
builtin function to provide different compile time selectable runtime behavior.
Example
Assert.swift:
@transparent
func assert<T : LogicValue>(
condition: @auto_closure () -> T, message: StaticString = StaticString(),
// Do not supply these parameters explicitly; they will be filled in
// by the compiler and aren't even present when asserts are disabled
file: StaticString = __FILE__, line: UWord = __LINE__
) {
// Only in debug mode.
if _isDebug() {
assert(condition().getLogicValue(), message, file, line)
}
}
AssertCommon.swift:
@transparent
func _isDebug() -> Bool {
return Int32(Builtin.assert_configuration()) == 0;
}
rdar://16458612
Swift SVN r16472
This commit adds infrastructure for conversion and testing it.
The conversion is still incomplete, pending discussion about which tags should
we use in the XML documents. I copied the RelaxNG schema from Clang, and will
edit it accordingly.
Swift SVN r16451
This commit also enables constant propagation in the performance
pipeline.
Since we are close to WWDC, this commit purposefully minimally touches
the pass (despite my hands wanted to refactor it so bad) just enough so
that we get the desired result with minimal in tree turmoil.
rdar://16604715
Swift SVN r16388
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
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
