We have long switched to delegate the checking of whether a module is up-to-date to the build system (SwiftDriver) and stopped serializing file dependencies for interface-built binary modules.
Resolves rdar://162881032
_SwiftifyImport assumes types like Swift.Int, Swift.UnsafePointer<T> and
Swift.Span<T> are available. This is not the case when building the
stdlib itself. Disable safe interop in the stdlib to prevent errors.
This currently has no effect, but will when this feature is enabled by
default, which I have manually tested.
The _SwiftifyImport macro is emitted into an unnamed buffer and then
parsed, pretending it was in the header all along. This makes it hard to
add `expected-note` comments for `diag::in_macro_expansion` when they
point here. That's okay, because the macro expansion has already been
pointed out by `expected-expansion` directives. But
-verify-ignore-unrelated is too blunt of a tool, so this adds
-verify-ignore-macro-note to ignore these specific diagnostics.
This pass has been disabled since a very long time (because it's terrible for code size).
It does not work for OSSA. Therefore it cannot be enabled anymore (as is) once we have OSSA throughout the pipeline.
So it's time to completely remove it.
This PR introduces three new instrumentation flags and plumbs them
through to IRGen:
1. `-ir-profile-generate` - enable IR-level instrumentation.
2. `-cs-profile-generate` - enable context-sensitive IR-level
instrumentation.
3. `-ir-profile-use` - IR-level PGO input profdata file to enable
profile-guided optimization (both IRPGO and CSIRPGO)
**Context:**
https://forums.swift.org/t/ir-level-pgo-instrumentation-in-swift/82123
**Swift-driver PR:** https://github.com/swiftlang/swift-driver/pull/1992
**Tests and validation:**
This PR includes ir level verification tests, also checks few edge-cases
when `-ir-profile-use` supplied profile is either missing or is an
invalid IR profile.
However, for argument validation, linking, and generating IR profiles
that can later be consumed by -cs-profile-generate, I’ll need
corresponding swift-driver changes. Those changes are being tracked in
https://github.com/swiftlang/swift-driver/pull/1992
Add support for the `Swift` availability domain, which represents availability
with respect to the Swift runtime. Use of this domain is restricted by the
experimental feature `SwiftRuntimeAvailability`.
When I added the `-index-store-compress` option, I forgot to translate it into the `FrontendOptions` struct, which rendered the command line option useless. Correctly set the value in `FrontendOptions` to fix this.
`llvm::Twine` is not valid after the end of the statement. Pass it
directly as a parameter without storing it in a local variable to
prevent UAF. Also updates DiagnosticVerifier tests to capture all
relevant output.
We already have -suppress-warnings and -suppress-remarks; this patch
adds support for suppressing notes too. Doing so is useful for -verify
tests where we don't really care about the emitted notes.
This commit adds -sil-output-path and -ir-output-path frontend options that
allow generating SIL and LLVM IR files as supplementary outputs during normal
compilation.
These options can be useful for debugging and analysis tools
workflows that need access to intermediate compilation artifacts
without requiring separate compiler invocations.
Expected behaviour:
Primary File mode:
- SIL: Generates one .sil file per source file
- IR: Generates one .ll file per source file
Single-threaded WMO mode:
- SIL: Generates one .sil file for the entire module
- IR: Generates one .ll file for the entire module
Multi-threaded WMO mode:
- SIL: Generates one .sil file for the entire module
- IR: Generates separate .ll files per source file
File Maps with WMO:
- Both SIL and IR outputs using first entry's naming, which is
consistent with the behaviour of other supplementary outputs.
rdar://160297898
This enables the previously added -verify-ignore-unrelated flag. When
-verify is used without -verify-ignore-unrelated, diagnostics emitted in
buffers other than the main file and those passed with
-verify-additional-file (except diagnostics emitted at <unknown>:0) will
now result in an error. They were previously ignored. The old behaviour
is still available as opt-in using -verify-ignore-unrelated.
This adds the implementation required for later changing the default
behaviour of the -verify flag to error when diagnostics are emitted
in buffers other than the main file and files added with
-verify-additional-file. To keep the current behaviour, use the flag
-verify-ignore-unrelated. This flag is added as a no-op so that tests
can start using it before the new behaviour is enabled by default.
When the diagnostic verifier encounters a fatal error, it reports:
<unknown>:0: error: fatal error encountered while in -verify mode
If we capture this, and fail to match this against an expected-error,
the diagnostic verifier complains:
<unknown>:0: error: unexpected error produced: fatal error encountered while in -verify mode
<unknown>:0: error: diagnostic produced elsewhere: fatal error encountered while in -verify mode
The current workaround is to use -verify-ignore-unknown, but that in
turn may mask actual errors coming from unknown source locations.
Ignoring these errors about errors removes the need for that workaround.
Introduce the ability to form a `StaticBuildConfiguration` from
language options. Add a frontend option `-print-static-build-config`
to then print that static build configuration as JSON in a manner that
can be decoded into a `StaticBuildConfiguration`.
Most of the change here is in sinking the bridged ASTContext queries
of language options into a new BridgedLangOptions. The printing of the
static build configuration only has a LangOptions (not an ASTContext),
so this refactoring is required for printing.
With some changes that I am making, we will no longer need this flag at the SIL
level, so we can just make it an IRGen flag (which it really should have been
in the first place).
