Regardless of any flags, the stdlib will have its generic metadata
prespecialized.
Temporarily reintroduced the flag to enable the feature flag while
preserving the flag to disable it and changed the default back to off
for the moment.
Previously, -Xfrontend -prespecialize-generic-metadata had to be passed
in order for generic metadata to be prespecialized. Now it is
prespecialized unless -Xfrontend
-disable-generic-metadata-prespecialization is passed.
This was being done at an odd point in the frontend presumably because by that point the private discriminator had been fully computed. Instead, push the conditions for generating the prefix data down to debug info generation and stop mutating IRGenOptions::DebugFlag in the frontend.
The new frontend flag -prespecialize-generic-metadata must be passed in
order for generic metadata to be specialized statically.
rdar://problem/56984885
The new option `-sanitize-recover=` takes a list of sanitizers that
recovery instrumentation should be enabled for. Currently we only
support it for Address Sanitizer.
If the option is not specified then the generated instrumentation does
not allow error recovery.
This option mirrors the `-fsanitize-recover=` option of Clang.
We don't enable recoverable instrumentation by default because it may
lead to code size blow up (control flow has to be resumable).
The motivation behind this change is that today, setting
`ASAN_OPTIONS=halt_on_error=0` at runtime doesn't always work. If you
compile without the `-sanitize-recover=address` option (equivalent to
the current behavior of the swift compiler) then the generated
instrumentation doesn't allow for error recovery. What this means is
that if you set `ASAN_OPTIONS=halt_on_error=0` at runtime and if an ASan
issue is caught via instrumentation then the process will always halt
regardless of how `halt_on_error` is set. However, if ASan catches an
issue via one of its interceptors (e.g. memcpy) then `the halt_on_error`
runtime option is respected.
With `-sanitize-recover=address` the generated instrumentation allows
for error recovery which means that the `halt_on_error` runtime option
is also respected when the ASan issue is caught by instrumentation.
ASan's default for `halt_on_error` is true which means this issue only
effects people who choose to not use the default behavior.
rdar://problem/56346688
This option is useful to debug the compiler itself, to simulate debug info as it
would be generated when producing optimized code, but without the unpredictable
output of an optimizing debugger.
Mixes the state of all sanitizers, not just the fuzzer, into the module hash used to decide whether to skip LLVM codegen. I don’t actually know of a case where one of the other sanitizers will generate identical IR and different machine code, but being defensive costs us very little.
Replaces getLLVMCodeGenOptionsHash(), which combined a bunch of individual bits into a string, with writeLLVMCodeGenOptionsTo(), which writes each one separately into a raw_ostream.
This is intended to be make the hashing more future-proof. The current design needs to know exactly how many bits each of the values needs; if any of the values grew and you forgot to update this function, its bits would interfere with those of an earlier value in the hash. This new design is expected to be slightly slower, but more robust to future change in the compiler.
When rebuilding a .o file, we hash the IR generated by IRGen and compare it to a hash embedded in the .o file. If they match, we simply skip asking LLVM to optimize and generate code. Certain flags that control our LLVM configuration are mixed into the hash, but the -profile-generate flag was not one of them. This usually wouldn’t matter because profiling would insert additional code into the IR, but in edge cases like empty files or files containing only protocol declarations, it could cause linker errors when profiling was turned off.
This change adds the `GenerateProfile` flag into the IR hash, ensuring that we always recompile, even if the IR was identical.
Fixes rdar://problem/54126622.
We use one bit of the third reserved swift private tls key.
Also move the functionality into a separate static archive that is
always linked dependent on deployment target.
Many build systems that support Swift don't use swiftc to drive the linker. To make things
easier for these build systems, also use autolinking to pull in the needed compatibility
libraries. This is less ideal than letting the driver add it at link time, since individual
compile jobs don't know whether they're building an executable or not. Introduce a
`-disable-autolink-runtime-compatibility` flag, which build systems that do drive the linker
with swiftc can pass to avoid autolinking.
rdar://problem/50057445
module imports. This is useful when building redistributable static
archives, since any pointers into the CLang module cache won't be
portable.
When using this option the Clang type fallback path in LLDB will be
less useful since DWARF type information from those modules will not
be available unless another object file compiled without the option
imported the same modules.
rdar://problem/48827784
In LLDB expressions, references to private metadata accessors may be
emitted and need to be bound to symbols available in the attached
program, even if these symbols are only supposed to have private
visibility within the program.
Also rdar://problem/48018240
Windows does not permit cross-module data accesses to be direct. This
is a problem for public protocols with root conformances which are
external. Use a runtime initialiser for the root protocol conformance
chaining to alleviate this issue. This shows up in the Foundation
build.
The layouts of resilient value types shipped in the Swift 5 standard library
x and overlays will forever be frozen in time for backward deployment to old
Objective-C runtimes. This PR ensures that even if the layouts of these types
evolve in the future, binaries built to run on the old runtime will continue
to lay out class instances in a manner compatible with Swift 5.
Fixes <rdar://problem/45646886>.
Add an IRGen flag to disable this verification, since it doesn't work from within
lldb itself for some reason, and I don't want to investigate it right now.
When -enable-anonymous-context-mangled-names is provided, emit mangled
names as part of the metadata of an anonymous context. This will allow
us to match textual mangled names to the metadata.
This is a backward-compatible ABI extension. Part of rdar://problem/38231646/.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
The metadata reference to the pre-exsting VWT cannot be supported on PE/COFF
due to the direct reference to a value in an external module that is in
static data (the model requires indirecting through memory). Always
force the lazy initialization for the metadata on such platforms.
This requires a secondary change - to initialize the VWT as well. This
is ideally moved into the runtime where we can do this uniformly.
The YAML format is the same one produced by the -dump-type-info
frontend mode.
For now this is only enabled if the -read-type-info-path frontend
flag is specified.
Progress on <rdar://problem/17528739>.
This flag is based on Clang's -fdebug-prefix-map, which lets the user remap absolute paths in debug info. This is necessary for reproducible builds and allows debugging to work on a different machine than the one that built the code when paths to the source may be different.
The other JIT modes all still build an entire local context into one LLVM module, so it's safe to form relative references, and necessary for reflection to work with private and local contexts. Only the integrated REPL needs this prohibition. Fixes rdar://problem/40607819.
When running Swift from within LLDB, we need to bypass resilience since LLDB
does not support resilience yet. However, the bypass was done too early as
part of the module loader, which had the effect of disabling resilience
altogether.
We still want resilience at the SIL level so that function types lower the
same with debugger support turned on and off. Only IRGen needs to bypass
resilience, so that LLDB can calculate fragile layouts of types. Also, the
DebuggerSupport flag is not always set in the ASTContexts created by LLDB.
So replace it with a new flag that only controls this behavior and nothing
else, and make it part of IRGenOptions to make it totally clear that it only
impacts IRGen.
Together with the paired LLDB change, fixes <rdar://problem/38719739>
and <rdar://problem/38483762>.
- Narrow the fix to classes with @objc ancestry only
- Pass -enable-class-resilience in class resilience executable test so that
we exercise resilience there
- Only enable fragile layout if the class has @objc ancestry
- Add an IRGen test
This commit is mostly refactoring.
*) Introduce a new OptimizationMode enum and use that in SILOptions and IRGenOptions
*) Allow the optimization mode also be specified for specific SILFunctions. This is not used in this commit yet and thus still a NFC.
Also, fixes a minor bug: we didn’t run mandatory IRGen passes for functions with @_semantics("optimize.sil.never")
This option tells the compiler where to find a profdata file. The
information in this file enables PGO. For more information about the PGO
infrastructure, look for the -profile-generate option and for the
llvm-profdata tool [1].
[1] http://llvm.org/docs/CommandGuide/llvm-profdata.html
This adds an size optimization mode ("Osize") which intends to enable some
optimization but targets mainly reduced code size compared to the regular
optimized mode ("O").
rdar://33075751
Similarly to Clang, the flag enables coverage instrumentation, and links
`libLLVMFuzzer.a` to the produced binary.
Additionally, this change affects the driver logic, and enables the
concurrent usage of multiple sanitizers.
Currently -Xcc options are serialized in Swift modules, but they are
not saved as attributes to the DW_TAG_module representing the imported
clang module. This patch saves all *user-specified* -D macros there,
but it does not save any macros that are added by the ClangImporter
itself.
<rdar://problem/31990102>
- Add CompilerInvocation::getPCHHash
This will be used when creating a unique filename for a persistent
precompiled bridging header.
- Automatically generate and use a precompiled briding header
When we're given both -import-objc-header and -pch-output-dir
arguments, we will try to:
- Validate what we think the PCH filename should be for the bridging
header, based on the Swift PCH hash and the clang module hash.
- If we're successful, we'll just use it.
- If it's out of date or something else is wrong, we'll try to
emit it.
- This gives us a single filename which we can `stat` to check for the
validity of our code completion cache, which is keyed off of module
name, module filename, and module file age.
- Cache code completion results from imported modules
If we just have a single .PCH file imported, we can use that file as
part of the key used to cache declarations in a module. Because
multiple files can contribute to the __ObjC module, we've always given
it the phony filename "<imports>", which never exists, so `stat`-ing it
always fails and we never cache declarations in it.
This is extremely problematic for projects with huge bridging headers.
In the case where we have a single PCH import, this can bring warm code
completion times down to about 500ms from over 2-3s, so it can provide a
nice performance win for IDEs.
- Add a new test that performs two code-completion requests with a bridging header.
- Add some -pch-output-dir flags to existing SourceKit tests that import a bridging
header.
rdar://problem/31198982
