Summary:
When the Swift driver executable was first added in
ed2038585f,
the code included a FIXME to support input types, like Clang's
`-x <language>` option. Perhaps as a first step in implementing this
functionality, it also included dead code that manipulated an input type
argument, even though the variable for storing the argument was never
written to.
Remove the unused input type code, and the FIXME. The FIXME is now
tracked with a Swift bug URL, so that a discussion on next steps can be had:
https://bugs.swift.org/browse/SR-6054
Test plan: `utils/build-script --release --test`
A post-commit reviewer on https://github.com/apple/swift/pull/10716
asked that the comments be removed. Remove them, as they're no longer
demarcating code that is internal to Apple.
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
Previously, Actions were responsible for freeing their inputs...
except for the ones that weren't. Or the ones that were supposed
to, but then they needed to share an input, so they couldn't anymore.
If this sounds ridiculous, you're right; now Actions are just
immediately allocated and owned by the Compilation.
The graph structure of the actions is still useful for some things; in
particular, "top-level" actions get to put their outputs somewhere
permanent rather than TMPDIR. But I expect these things to get cleaned
up in the future too.
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.
This means it can be emitted during an -emit-module frontend job, which is the
most common place it will be used, so reusing work like this is important for
performance.
For now, this has to happen as part of a single frontend invocation, i.e. -wmo
or -force-single-frontend-invocation.
With this patch different sanitizers (tsan/asan) will be enabled or
disabled on the driver level on a particular OS depending on whether
the required library is present.
The current patch only supports Darwin architectures, but Linux support
should not be hard to add.
Previously it was passing a relative filename and the invocation was creating .dia files in the source directory.
If a filename is not determined for inside the PCH output directory, it fallsback to creating a temporary for the diagnostics file,
similarly to the non-persistent bridging PCH job.
rdar://32594291
This helps disambiguate files that might otherwise be hard to sort through
if multiple runs output stats together in a single directory. The names
don't have to be perfect, just contain sufficient hints (and be parseable)
to differentiate module, arch, opt and output-type variation in jobs.
For the multiple-files mode -emit-pch is still invoked in separate frontend invocation but with using a persistent PCH.
Subsequent frontend invocations use the persistent PCH but they don't need to validate it.
For all-files mode (e.g. WMO) the frontend invocation uses a persistent PCH that it also validates.
Replace `NameOfType foo = dyn_cast<NameOfType>(bar)` with DRY version `auto foo = dyn_cast<NameOfType>(bar)`.
The DRY auto version is by far the dominant form already used in the repo, so this PR merely brings the exceptional cases (redundant repetition form) in line with the dominant form (auto form).
See the [C++ Core Guidelines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#es11-use-auto-to-avoid-redundant-repetition-of-type-names) for a general discussion on why to use `auto` to avoid redundant repetition of type names.
I had set up the driver to invoke a separate frontend invocation with
the "update code" mode. We sort of did this last release, except we
forked to the swift-update binary instead. This is causing problems with
testing in Xcode.
Instead, let's perform a single compile and add the remap file as an
additional output during normal compiles. The driver, seeing
-update-code, will add -emit-remap-file-path $PATH to the -c frontend
invocation.
rdar://problem/31857580
