As is, you cannot set all default fuzzer options directly using -sanitize-coverage. Because of this you can use default fuzzer sanitize-coverage args, or a limited number coverage options.
This PR adds pc-table and inline-8bit-counter as valid args to be parsed for sanitize-coverage flag. These are default fuzzer options -- and will allow customizing sanitizer-coverage in variations of fuzzer defaults. (i.e. w/o pc-table enabled).
In upstream clang the option -fno-sanitize-coverage exists to disable various coverage options. Swift currently does not have a convention of using excluding args for sanitizer flags. This aims to limit the need for a new flag by inclusively setting desired coverage up to current fuzzer defaults.
rdar://127881891
`OptTable` was a source of consistent churn due to new arguments to the
`OPTION` macro. LLVM 3f092f37b7362447cbb13f5502dae4bdd5762afd extracted
the handling of the common option parts (eg. an ID and an info) out into
separate macros to reduce this - use those here (since unsurprisingly,
more arguments were added).
Avoid path encoding difference (for example, real_path vs. path from
symlink) by eliminating the path from cache key. Cache key is now
encoded with the index of the input file from all the input files from
the command-line, reguardless if those inputs will produce output or
not. This is to ensure stable ordering even the batching is different.
Add a new cache computation API that is preferred for using input index
directly. Old API for cache key is deprecated but still updated to
fallback to real_path comparsion if needed.
As a result of swift scan API change, rename the feature in JSON file to
avoid version confusion between swift-driver and libSwiftScan.
rdar://119387650
This patch adds a new flag sanitize-stable-abi to support linking
against the Sanitizers stable ABI added recently in compiler-rt. The
patch also passes extra options for the ASan pass when using this flag
to outline instrumentation code and remove version check.
rdar://112915278
Scudo is now a standalone sanitizer that must be used in isolation.
Fixing the driver logic to identify and diagnose when it is used with
any other sanitizer.
Reformatting everything now that we have `llvm` namespaces. I've
separated this from the main commit to help manage merge-conflicts and
for making it a bit easier to read the mega-patch.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
This change adds to the extracted type metadata the following fields:
- Conformances: this is a list of all protocols that the given nominal type conforms to
- associated type aliases: this is a list of all associated types across all conformances that the given nominal type substitutes with concrete types. For a given associated type, we gather:
- Associated type name
- Substituted type's fully-qualified name
- Substituted type's mangled name
- If the substituted type is opaque:
- List of conformance requirements of this opaque type
- List of same-type requirements of this opaque type
`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
The old API will be deprecated in the rebranch.
To avoid merge conflicts, use the new API already in the main branch.
rdar://102362022
- Add driver and frontend option
- Add LangOptions entry
- Ensure driver propagates flag to frontends
- Add feature to `features.json`
Part of rdar://91119995
Explicitly invoke the script executor rather than the script as running a script is meaningless. Shebangs are not a portable manner of indicating the script executor and worse yet do not guarantee portability on such systems either. Ideally the shebang line would be removed from the script.
Thanks to @pcbeard for reporting the issue!
Clang has a new `redirecting-with` property in the VFS overlay files.
While this could be added to Swift's features as well, it is generally
the case that features provided by Clang can also be useful to know for
clients of Swift. Merge the features from Clang into Swift's features
file with the "clang-" prefix to differentiate them.
Clang has a new `redirecting-with` property in the VFS overlay files.
While this could be added to Swift's features as well, it is generally
the case that features provided by Clang can also be useful to know for
clients of Swift. Merge the features from Clang into Swift's features
file with the "clang-" prefix to differentiate them.
6e683ca823 removed the warning that was
being output when `-index-unit-output-path` was given without
`-index-store-path`. Add a feature flag to mark the compiler as having
removed this warning.
Resolves rdar://86833719.
Set the flag to indicate the availability of the -library-level flag in
the compiler and driver. As driver submissions can be delayed we are
integrating this flag late as a safety measure.
rdar://82742547
The frontend supports this via new options -index-unit-output-path and
-index-unit-output-path-filelist that mirror -o and -output-filelist. These are
intended to allow sharing index data across builds in separate directories (so
different -o values) that are otherwise equivalent as far as the index data is
concerned (e.g. an ASAN build and a non-ASAN build) by supplying the same
-index-unit-output-path for both.
This change updates the driver to add these new options to the frontend
invocation 1) when a new "index-unit-output-path" entry is specified for one
or more input files in the -output-file-map json or 2) if -index-file is
specified, when a new -index-unit-output-path driver option is passed.
Resolves rdar://problem/74816412
Previously Swift enabled the "UseOdrIndicator" ASan instrumentation mode
and gave no option to disable this. This probably wasn't intentional but
happened due to the fact the
`createModuleAddressSanitizerLegacyPassPass()` function has a default
value for the `UseOdrIndicator` parameter of `true` and in Swift we
never specified this parameter explicitly.
Clang disables the "UseOdrIndicator" mode by default but allows it to be
enabled using the `-fsanitize-address-use-odr-indicator` flag.
Having "UseOdrIndicator" off by default is probably the right
default choice because it bloats the binary. So this patch changes the
Swift compiler to match Clang's behavior.
This patch disables the "UseOdrIndicator" mode by default but adds a
hidden driver and frontend flag (`-sanitize-address-use-odr-indicator`)
to enable it. The flag is hidden so that we can remove it in the future
if needed.
A side effect of disabling "UseOdrIndicator" is that by we will no
longer use private aliases for poisoning globals. Private aliases were
introduced to avoid crashes
(https://github.com/google/sanitizers/issues/398) due to ODR violations
with non-instrumented binaries. On Apple platforms the use of two-level
namespaces probably means that using private aliases wasn't ever really
necessary to avoid crashes. On platforms with a flat linking namespace
(e.g. Linux) using private aliases might matter more but should users
actually run into problems they can either:
* Fix their environment to remove the ODR, thus avoiding the crash.
* Instrument the previously non-instrumented code to avoid the crash.
* Use the new `-sanitize-address-use-odr-indicator` flag
rdar://problem/69335186
