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.
Introduce a new flag `-export-as` to specify a name used to identify the
target module in swiftinterfaces. This provides an analoguous feature
for Swift module as Clang's `export_as` feature.
In practice it should be used when a lower level module `MyKitCore` is
desired to be shown publicly as a downstream module `MyKit`. This should
be used in conjunction with `@_exported import MyKitCore` from `MyKit`
that allows clients to refer to all services as being part of `MyKit`,
while the new `-export-as MyKit` from `MyKitCore` will ensure that the
clients swiftinterfaces also use the `MyKit` name for all services.
In the current implementation, the export-as name is used in the
module's clients and not in the declarer's swiftinterface (e.g.
`MyKitCore`'s swiftinterface still uses the `MyKitCore` module name).
This way the module swiftinterface can be verified. In the future, we
may want a similar behavior for other modules in between `MyKitCore` and
`MyKit` as verifying a swiftinterface referencing `MyKit` without it
being imported would fail.
rdar://103888618
This lets users of `-explicit-swift-module-map-file` use a single mapping
for all module dependencies, regardless of whether they're Swift or Clang
modules, instead of manually splitting them among this file and command
line flags.
Not aliasing the stdlib should allows it to be used in inlinable code.
Since builtin isn't imported explicitly, references to it shouldn't use
the alias.
rdar://104582241
The SwiftDiagnostics module within swift-syntax has a diagnostic
pretty-printer that does a nice rendering of the source code with
diagnostics placed inside gaps between the code lines.
Introduce another `-diagnostic-style` argument, `swift-syntax`,
to bridge from the pretty-printed C++ diagnostics over to the
swift-syntax diagnostics engine.
File IDs have been expressed using a 10-bit fixed field. This limits us
to 1023 different files in which we can emit diagnostics, where
overflowing would simply crash. With the introduction of macros and
their generated source buffers, we're much more likely to overflow.
Switch to a 5-bit VBR field, which is slightly smaller for the common
case where there are few files involving diagnositcs, and which also
allows us to have up to 2^32-1 file IDs.
When emitting generated source file buffers, we could end up
reallocating the DenseMap that tracks file IDs while still holding a
reference to it. Hilarity ensues. Stop that hilarity by taking a copy.
Additionally, make sure we don't emit an invalid source range, and
instead put in empty source locations.
Extend the serialized diagnostics file format to also support providing
the contents of source files, which can include a reference to the
"original source range" whose text is conceptually replaced with the
contents of the serialized diagnostics file, e.g., due to macro
expansion.
