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
TAPI and the linker truncate individual version components to 255 if
they overflow, because the linker packs 3 version components into a
32-bit int. Make sure we use the same parsing routines as TAPI.
Fixes rdar://57043178
This flag, currently staged in as `-experimental-skip-non-inlinable-function-bodies`, will cause the typechecker to skip typechecking bodies of functions that will not be serialized in the resulting `.swiftmodule`. This patch also includes a SIL verifier that ensures that we don’t accidentally include a body that we should have skipped.
There is still some work left to make sure the emitted .swiftmodule is exactly the same as what’s emitted without the flag, which is what’s causing the benchmark noise above. I’ll be committing follow-up patches to address those, but for now I’m going to land the implementation behind a flag.
This commit also includes cases where user uses -Fsystem and when path
ends in ".framework/"
(cherry picked from commit a5d9750a9d25441517f3bec97488f57d1bb4b03f)
A dependency being removed is not a hard error, because the recovery step is to recompile the interface. That might fail because of the change in dependencies, but that is a more actionable error.
Fixes rdar://51959698
Keep track of information that led the module interface loader to reject loading a compiled module, if it needed to fall back to compiling an interface.
rdar://47792754
Module interfaces don't yet carry enough information to correctly
describe the binary interface of a module compiled without
-enable-library-evolution, but we don't want to make this an error
because that would make it harder to work towards getting it in the
future.
If the project ever drops Swift 4 mode or Swift 4.2 mode, that would
break modules using those modes in their interface, so put an
unsilenceable warning in for using those modes to nudge interface
emitters to Swift 5.
rdar://problem/47792595
This was a nice feature when people said "-swift-version 3.1"...
up until we got "-swift-version 4.2" as an actual valid version.
Just drop the special case.
https://bugs.swift.org/browse/SR-8850
We already have something called "module interfaces" -- it's the
generated interface view that you can see in Xcode, the interface
that's meant for developers using a library. Of course, that's also a
textual format. To reduce confusion, rename the new module stability
feature to "parseable [module] interfaces".
...but don't hook it up to anything yet.
This is the very very start of the module stability / textual
interfaces feature described at
https://forums.swift.org/t/plan-for-module-stability/14551/
For now I've just made it a frontend option (not a driver option),
which is good enough for testing.
Parse-only invocations do not support the proper creation of dependency files or reference dependency files because they have not yet run name binding. Ban these invocations by diagnostic and add a new diagnostic specifically for reference dependencies.
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.
- Outlaw duplicate input files, fix driver, fix tests, and add test.
- Reflect that no buffer is present without a (possibly pseudo) named file.
- Reflect fact that every input has a (possible pseudo) name.
- Break up CompilerInstance::setup.
Don't bail on dups.
This allows reporting successful and unsuccessful optimizations similar to
clang/llvm.
This first patch adds support for the
options -Rpass=<pass-name-regex> -Rpass-missed=<pass-name-regex>. These allow
reporting successful/unsuccessful optimization on the compiler output for passes
specified by the regex. I've also added one missed and one passed remark type
to the inliner to test the infrastructure.
Clang also has the option of collecting these records in an external YAML data
file. This will be added in a later patch.
A few notes:
* The goal is to use this facility for both user-lever "performance" warnings
and expert-level performance analysis. There will probably be a flag in the
future differentiating the verbosity.
* The intent is match clang/llvm as much as it makes sense. On the other hand I
did make some changes. Unlike in llvm, the emitter is not a pass which
simplifies things. Also the remark class hierarchy is greatly simplified since
we don't derive from DiagnosticInfo. We also don't derive from Diagnostic to
support the streaming API for arbitrary named-value pairs.
* Currently function names are printed mangled which should be fixed.
