For clients, such as the debugger, who do not have access the full
output of the dependency scanner, it is a huger performance and
correctness improvement if each explicitly built Swift module not just
serialized all its Clang .pcm dependencies (via the serialized Clang
compiler invocation) but also its direct Swift module dependencies.
This patch changes the Swift module format to store the absolute path
or cas cache key for each dependency in the INPUT block, and makes
sure the deserialization makes these available to the ESML.
rdar://150969755
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.
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 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.
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.
This change refactors the module loaders to explicitly take a parameter indicating whether or not the loader is handling a 'canImport' query, in order to avoid emitting an error when finding a dependency Swift binary module with only imcompatible architecture variants present.
Resolves rdar://161175498
Replace the one-off compiler flag for Library Evolution with an
optional language feature. This makes the
`hasFeature(LibraryEvolution)` check work in an `#if`, and is
otherwise just cleanup.
Tracked by rdar://161125572.
The flags "-import-bridging-header" and "-import-pch" import a bridging
header, treating the contents as a public import. Introduce
"internal-" variants of both flags that provide the same semantics,
but are intended to treat the imported contents as if they came in
through an internal import. This is just plumbing of the options for
the moment.
Since freestanding macro expansion buffer names include the line number
of their invocation, it can become quite fiddly to try to update a test
file with multiple macro expansions. This adds the option to use an
expected-expansion block and use a relative line number, nesting other
expected diagnostic statements inside this block.
Example syntax:
```swift
let myVar = #myMacro
/*
expected-expansion@-2:1{{
expected-error@13:37{{I can't believe you've done this}}
expected-note@14:38{{look at this and ponder your mistake}}
}}
*/
```
An always enabled availability domain is implicitly available in all contexts,
so uses of declarations that are marked as `@available` in the domain are never
rejected. This is useful for an availability domain representing a feature flag
that has become permanently enabled.
Partially resolves rdar://157593409.
This change introduces a thread-safe version of the 'SerializedDiagnosticConsumer' and refactors scanning compilation instance creation code to ensure this consumer gets added when the scanner query configuration command-line includes '-serialized-diagnostics-path' option.
Parser errors with large Swift module map files can be hard to diagnose.
Refactor the parser to return an llvm::Error so clearer diagnostics can
be passed to the user.
SwiftVerifyEmittedModuleInterface job is configured to be built within
the SubInvocation and it needs to inherit the caching replay prefix map
in order to load macro plugin library correctly.
rdar://158692095
When building a module interface for the -typecheck-module-from-interface or
-compile-module-from-interface actions, inherit and honor compiler debugging
options and emit debugging output at the end of the interface build.
Add a new option `-gen-reproducer` that when swift caching is used,
create a standalone reproducer that can be used to reproduce the
`swift-frontend` invocation.
Previously this flag was only used to pass explicit dependencies to compilation tasks. This change adds support for the dependency scanner to also consider these inputs when resolving dependencies.
Resolves https://github.com/swiftlang/swift-driver/issues/1951
Create a path that swift-frontend can execute an uncached job from
modules built with CAS based explicit module build. The new flag
-import-module-from-cas will allow an uncached build to load module
from CAS, and combined with source file from real file system to build
the current module. This allows quick iterations that bypasses CAS,
without full dependency scanning every time in between.
rdar://152441866
Using IncludeTree::FileList to concat the include tree file systems that
are passed on the command-line. This significantly reduce the
command-line size, and also makes the cache key computation a lot
faster.
rdar://148752988
Previously we would insert StringRefs that reference the keys in the
map, but that breaks if the invocation ever gets copied. Switch to
`std::string`.
rdar://148130166
The "featues" part was never actually implemented and Swift Driver
is replying on information about arguments, so instead of removing
this mode, let's scope it down to "arguments" to be deprecated in
the future.
This is a replacement for `-emit-supported-features` that prints
all of the upcoming/experimental features supported by the compiler
with some additional meta information in JSON format to stdout.
We've been converging the implementations of educational notes and
diagnostic groups, where both provide category information in
diagnostics (e.g., `[#StrictMemorySafety]`) and corresponding
short-form documentation files. The diagnostic group model is more
useful in a few ways:
* It provides warnings-as-errors control for warnings in the group
* It is easier to associate a diagnostic with a group with
GROUPED_ERROR/GROUPED_WARNING than it is to have a separate diagnostic
ID -> mapping.
* It is easier to see our progress on diagnostic-group coverage
* It provides an easy name to use for diagnostic purposes.
Collapse the educational-notes infrastructure into diagnostic groups,
migrating all of the existing educational notes into new groups.
Simplify the code paths that dealt with multiple educational notes to
have a single, possibly-missing "category documentation URL", which is
how we're treating this.
We're moving over to a model where we provide direct links to educational notes /
diagnostic group notes whenever relevant. Rendering the Markdown from these
files to the terminal is less relevant with this approach, so remove it from the
compiler.
An objcImpl bug previously caused `@_hasStorage` to be emitted inside some extensions in module interfaces. An earlier commit in this PR created an error for this, but for backwards compatibility, it would actually be better to simply ignore the attribute in module interfaces. Modify TypeCheckStorage to emit a warning, not an error, in this situation.
Additionally, modify the module interface loader to show warnings when you verify a module interface, but not for other module interface uses (like compiling or importing one). The assumption here is that if you’re verifying a module interface, you’re either the author of the module that created it or you’re investigating a problem with it, and in either case you’d like to be told about minor defects in case they’re related.
Fixes rdar://144811653 thoroughly.
