Tool selection is primarily done by checking the executable (= symlink) name.
But sometimes (e.g. if the tool symlink is not there) it's useful to have an option for selecting the tool.
The selection option (e.g. -sil-opt) must be the first argument of swift-frontend.
Add a CachedDiagnosticsProcessor that is a DiagConsumer can capture all
the diagnostics during a compilation, serialized them into CAS with a
format that can be replayed without re-compiling.
Using a virutal output backend to capture all the outputs from
swift-frontend invocation. This allows redirecting and/or mirroring
compiler outputs to multiple location using different OutputBackend.
As an example usage for the virtual outputs, teach swift compiler to
check its output determinism by running the compiler invocation
twice and compare the hash of all its outputs.
Virtual output will be used to enable caching in the future.
Once the API has gone through Swift Evolution, we will want to implicitly
import the _Backtracing module. Add code to do that, but set it to off
by default for now.
rdar://105394140
Add frontend flag `-emit-macro-expansion-files diagnostics` to emit any
macro expansion buffers referenced by diagnostics into files in a
temporary directory. This makes debugging type-checking failures in
macro expansions far easier, because you can see them after the
compiler process has exited.
When opaque values are enabled, TypeConverter associates to an
address-only type an OpaqueValueTypeLowering. That lowering stores a
single lowered SIL type, and its value category is "object". So long as
the module has not yet been address-lowered, that type has the
appropriate value category. After the module has been address-lowered,
however, that type has the wrong value category: the type is
address-only, and in an address-lowered module, its lowered type's value
category must be "address".
Code that obtains a lowered type expects the value category to reflect
the state of the module. So somewhere, it's necessary to fixup that
single lowered type's value category.
One option would be to update all code that uses lowered types. That
would require many changes across the codebase and all new code that
used lowered types would need to account for this.
Another option would be to update some popular conveniences that call
through to TypeConverter, for example those on SILFunction, and ensure
that all code used those conveniences. Even if this were done
completely, it would be easy enough for new code to be added which
didn't use the conveniences.
A third option would be to update TypeLowering::getLoweredType to take
in the context necessary to determine whether the stored SILType should
be fixed up. That would require each callsite to be changed and
potentially to carry around more context than it already had in order to
be able to pass it along.
A fourth option would be to make TypeConverter aware of the
address-loweredness, and to update its state at the end of
AddressLowering.
Updating TypeConverter's state would entail updating all cached
OpaqueValueTypeLowering instances at the end of the AddressLowering
pass. Additionally, when TypeConverter produces new
OpaqueValueTypeLowerings, they would need to have the "address" value
category from creation.
Of all the options, the last is least invasive and least error-prone, so
it is taken here.
We cannot filter all libraries because duplicate -l flags have a semantic meaning based on their order, but filtering out just the common Swift libraries should yield a good size improvement already and is safe.
`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
The old API will be deprecated in the rebranch.
To avoid merge conflicts, use the new API already in the main branch.
rdar://102362022
Previously the driver mode was always set based on the executable name,
ignoring any manually passed flag, now this flag is preferred if it
exists.
Fixes https://github.com/apple/swift/issues/60600
This includes:
- bumping the SWIFT_SYMBOLGRAPH_FORMAT_MINOR version
- introduction of the "swift.extension" symbol and "extensionTo" relationship
- adding support for ExtensionDecl to the Symbol class
- adding a "typeKind" field to the symbol's extension mixin which indicates what kind
of symbol was extended
- intoduction of the -emit-extension-block-symbols flag, which enables the behavior
outlined below
- adaptions to SymbolGraphASTWalker that ensure a swift.extension symbol is emitted
for each extension to a type that does not exist in the local symbol graph
- adaptions to SymbolGraph and SymbolGraphASTWalker that ensure member and conformance
relationships are correctly associated with the swift.extension symbol instead of
the original type declaration's (extended nominal's) symbol where applicable
- adaptions to SymbolGraphASTWalker that ensure swift.extension symbols are connected
to their respective extended nominal's symbol using an extensionTo relationship
Testing:
- adds SymbolGraph tests that test behavior only relevant in
-emit-extension-block-symbols mode
- adapts some SymbolGraph tests to additionally test similar behavior for
extensions to external types in -emit-extension-block-symbols mode
- adapts some SymbolGraph tests to (additionally or exclusively) test the
behavior with -emit-extension-block-symbols mode enabled
Bugfixes:
- fixes a bug where some conformsTo relationships implicated by the conformances
declared on an extension to an external type were not emitted
(see test/SymbolGraph/Relationships/ConformsTo/Indirect.swift)
Further changes:
- documents the strategy for naming and associating children declared in extensions
to typealiases (see test/SymbolGraph/Relationships/MemberOf/Typealias.swift,
test/SymbolGraph/Symbols/Names.swift)
Basic should not be allowed to link Parse, yet it was doing so
to allow Version to provide a constructor that would conveniently
parse a StringRef. This entrypoint also emitted diagnostics, so it
pulled in libAST.
Sink the version parser entrypoint down into Parse where it belongs
and point all the clients to the right place.
SwiftOnoneSupport is automatically imported in the debug mode. When diffing the release build with
a baseline genearted in the debug build, we may hit this false positive.
