In multi-threaded WMO builds, the frontend didn't properly handle per-file
supplementary outputs specified via output file maps or command-line
arguments.
This enables swift-driver to use -supplementary-output-file-map for
per-file outputs in multi-threaded WMO, instead of generating multiple
individual flags that the frontend rejects.
By calling `printCommon` twice, this inserts a JSON object into
another JSON object without a key. This asserts inside LLVM's
JSON helper, but only if the compiler is built with assertions
enabled (which Xcode's compiler doesn't).
This also fixes the S-expression version, which is similarly busted:
```
(pattern_entry
(async_let type="Int" (pattern_any type="Int")
(original_init=call_expr type="Int" ...
```
This avoids infinite recursion when a function captures itself; e.g.,
```swift
func foo() {
func bar() {
bar()
}
bar()
}
```
It also just avoids printing unnecessarily verbose information,
since those decls would have already been dumped elsewhere in the
tree.
`ModuleType`s show up in some rare places, like the left-hand-side of
a `DotSyntaxBaseIgnoredExpr` for a module-qualified function call.
ASTMangler does not support these because they're not real types.
`verifyUnknown()` and `verifyUnrelated()` would not remove the
diagnostics after reporting their errors, leading to the same
diagnostics then being emitted a second time. This removes them from the
list after emitting them, just like `verifyFile()` does.
This makes it more explicit and consistent, which are good properties
for test output. It makes it easier both for humans and
update-verify-tests to see what exactly is going on. This does not
affect how diagnostics are displayed to users normally.
This won't affect diagnostic printing, as the diagnostic engine checks
the GeneratedSourceInfoKind and stops expanding if it's an
AttributeFromClang kind. This helps the diagnostic verifier expand to
the original location in source code however.
...-verify-additional-file
It's not expected that users add macro expansion buffer names to
-verify-additional-file. The recommended approach is to add the actual
source file that the macro was expanded in, and use expected-expansion.
This adds the -Rmacro-expansions flag. It provides similar functionality
to -dump-macro-expansions, but instead of dumping the macro expansion to
stderr, it emits it line by line as remarks. This is useful for testing
with -verify, where both macro expansion content and warnings need to be
tested at the same time.
There are a few places in the AST dumper where it prints hexadecimal
pointer addresses. This can be useful when dumping nodes in the
debugger, but it makes the output nondeterministic when can cause
problems for build systems that cache outputs.
In the JSON format only, replace these pointers with the string
`"replaced-pointer-XX"`, where `XX` is an increasing integer ID.
We keep track of the pointers that have been replaced so that the
same pointer always maps to the same ID; this means that those
nodes can still be related to each other when reading the AST
later, if needed.
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
`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.
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
These are tests that fail in the next commit without this flag. This
does not add -verify-ignore-unrelated to all tests with -verify, only
the ones that would fail without it. This is NFC since this flag is
currently a no-op.
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.
If someone has configured their build to add some vendor macro, for
example, the vendor macro will appear in `customConditions`, which will
make the test fail.
Modify the test slightly to check for `customConditions` containing
`"SOMETHING"`, instead of only being `["SOMETHING"]` and nothing else.
This should still allow the test to pass in Swift CI, but allows vendor
macros to work too.
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.
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.
Set an upper bound on the number of chained lookups we attempt to
avoid spinning while trying to recursively apply the same dynamic
member lookup to itself.
rdar://157288911
Optional language features don't have a specific "-enable-*" flag, because
they're rare and don't fit the same upcoming/experimental distinction. Add
a flag_name field to provide the flag name as well.
The name of a migratable feature might differ from the names of the
diagnostic groups containing the diagnostics that are used to drive
migration for that feature. Provide the set of diagnostic categories
that are associated with each migratable feature as part of the
supported features list.
-nostdimport and -nostdlibimport only remove the toolchain and usr/lib/swift search paths, and they leave the framework search paths intact. That makes it impossible to get a fully custom SDK environment. Make their behavior match clang's -nostdinc/-nostdlibinc behavior: treat framework and non-framework paths the same. In other words, -nostdinc removes *all* compiler provided search paths, and -nostdlibinc removes *all* SDK search paths.
Rename SkipRuntimeLibraryImportPaths to SkipAllImportPaths, and ExcludeSDKPathsFromRuntimeLibraryImportPaths to SkipSDKImportPaths to reflect their updated behavior.
Move the DarwinImplicitFrameworkSearchPaths handling from SearchPathOptions to CompilerInvocation, where RuntimeLibraryImportPaths is managed. Rename it to just ImplicitFrameworkSearchPaths, and filter for Darwin when it's set up so that all of the clients don't have to do Darwin filtering themselves later.
rdar://150557632
This is future-proofing the version part of the upcoming
feature. There currently no features that require that
but it's possible that they'd be added in the future.
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.
SymbolGraph generation iterating over llvm::DenseSet, which makes the
symbols and relationship fields appear in non-deterministic ordering.
Switch to use llvm::SetVector to preserve the insertion order from
SourceEntityWalker to make order deterministic.
Resolves: https://github.com/swiftlang/swift/issues/59602
- For type USRs, use `mapTypeOutOfContext()` to replace primary
archetypes with type parameters. If the type contains local
archetypes, replace them with their existential upper bounds.
- For inheritance of types, print the derived semantic information
instead of the inheritance list as it is written.
- Dump conformance requirements as protocol decl USRs instead of
type USRs, since the latter involves an existential conversion
that loses suppressed protocols.
- Fix a small bug in conformance dumping where the `MemberLoading`
field wasn't propagated to the nested printer, which caused
protocols to be dumped as simple names instead of USRs.
