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.
PR #78793 moved the code that this test was testing for into `NDEBUG`
blocks, which means that only exist in assert toolchains. The test was
not changed, so it was failing in non-assert toolchains.
Use a null diagnostic consumer in the deterministic verify instance. The
constraint system will skip work if there are no consumer in the
diagnostic engine. Use a null consumer to make sure the same amount of
work is done for two runs.
Make sure the traversal order for classMembers in deterministic in the
mdoule by sorting them first.
Also fix the comparsion function for `DeclName` to make sure there
aren't two DeclNames with different OpaquePointer can be evaluated to
equal.
rdar://147513165
Fix the non-deterministic .swiftdeps output. In contrary to the comments
in the `FineGrainedDependencies.h`, the non-determinism is not because
of the use of unordered_* data structure there. Those data structures
are not traversed so removing all the unused traversing methods to avoid
the confusion.
The true reason for the non-determinism is all the DenseSet in the
Evaluator dependency tracking, that causes the FineGrainedDependencies
to see arbitrary ordering. Use `SetVector` instead to keep track of the
insertion order to make dependency output to be deterministic.
rdar://104876331
`#fileID` never accounted for the possibility that someone one have
a module alias _itself_, so it always generated the module's real
(physical) name. This _technically_ changes the behavior of `#fileID`
for self-aliased modules, but since nobody would have ever had a reason
to do that before raw identifiers, it's unlikely that this change would
affect anyone in practice.
For build systems that already generate these files, it makes sense to include the aliases so that the map file serves as a comprehensive index of how the module inputs are referenced.
The original module names themselves must still be valid unescaped identifiers; most of the serialization logic in the compiler depends on the name of a module matching its name on the file system, and it would be very complex to turn escaped identifiers into file-safe names.
