Consider the case of A -> B. The previous workaround will add a
forced-B-dep.swift to A that is touched if B rebuilds. So if B is
rebuilt, A is also rebuilt. But A itself has no real changes, and so
none of its object files are built and none of the mtimes are updated.
Thus, A is then rebuilt again on the next run because its input
(forced-B-dep.swift) is newer than the corresponding object file. To
prevent this, update the mtime for the library and object files after the
build (which is actually a link step that both compiles and links).
Use the new "grouped diagnostics" feature of the swift-syntax
diagnostic rendering to emit printed diagnostics under the
swift-syntax diagnostic style. This emits macro expansion buffers as
text to the terminal, inset in a box where the macro was expanded, so
that there is more context for understanding how the macro was
expanded and what went wrong inside it.
Executable compiler plugins are programs invoked by the host compiler
and communicate with the host with IPC via standard IO (stdin/stdout.)
Each message is serialized in JSON, prefixed with a header which is a
64bit little-endian integer indicating the size of the message.
* Basic/ExecuteWithPipe: External program invocation. Lik
llvm::sys::ExecuteNoWait() but establishing pipes to the child's
stdin/stdout
* Basic/Sandbox: Sandboxed execution helper. Create command line
arguments to be executed in sandbox environment (similar to SwiftPM's
pluging sandbox)
* AST/PluginRepository: ASTContext independent plugin manager
* ASTGen/PluginHost: Communication with the plugin. Messages are
serialized by ASTGen/LLVMJSON
rdar://101508815
The runtime compat 5.6 library is not available in current toolchains.
The stage-0 compiler builds fine since the builder compiler is not aware
of the 5.6 library, but the stage-1 compiler will not link since the
builder libraries don't have the compat 5.6 library, while the stage-0
compiler is aware of the library and attempts to link it into the built
products. The issue is that the bootstrap goes and uses the libraries
off of the builder instead of the things that actually match the
compiler.
This is currently safe because the 5.6 compat library only contains
concurrency runtime fixes and the compiler frontend does not use
concurrency yet. If this changes, we will need to re-enable this and
make the bootstrap use the libraries correctly.
Rather than trying to patch up the "basic" macro expansion context
that comes from the swift-syntax package, implement our own based
on the new SourceManager. Fixes the `location(of:)` operation.
We can get into a situation where the C++ parser has emitted a warning but no error and thus `hadAnyError()` is still `false`. Suppress warnings from SwiftParser to avoid emitting the same warning that we already emitted from the C++ parser from SwiftParser.
Errors that were thrown out of a macro implementation were being
emitted and then lost. The result of this is a SILGen assertion later
on, if there were no other errors in the code.
Make sure we properly emit these diagnostics through the source
manager, which required fixing an issue in the offset computation used
for diagnostics.
Introduce SingleValueStmtExpr, which allows the
embedding of a statement in an expression context.
This then allows us to parse and type-check `if`
and `switch` statements as expressions, gated
behind the `IfSwitchExpression` experimental
feature for now. In the future,
SingleValueStmtExpr could also be used for e.g
`do` expressions.
For now, only single expression branches are
supported for producing a value from an
`if`/`switch` expression, and each branch is
type-checked independently. A multi-statement
branch may only appear if it ends with a `throw`,
and it may not `break`, `continue`, or `return`.
The placement of `if`/`switch` expressions is also
currently limited by a syntactic use diagnostic.
Currently they're only allowed in bindings,
assignments, throws, and returns. But this could
be lifted in the future if desired.
Use the name mangling scheme we've devised for macro expansions to
back the implementation of the macro expansion context's
`getUniqueName` operation. This way, we guarantee that the names
provided by macro expansions don't conflict, as well as making them
demangleable so we can determine what introduced the names.
Add SourceManager that can keep track of multiple source file syntax
nodes along with their external representations. The source manager can
emit diagnostics into any of those files, including tracking any
explicitly "detached" syntax nodes used for macro expansion.
Make sure we detach syntax nodes before passing them to macro
implementations, so they cannot see more of the source file than they
are permitted. We hadn't been doing this before (by accident), and
doing so motivated the introduction of the SourceManager.
Additionally, perform operator folding on macro arguments as part of
detaching them. Macro clients shouldn't have to do this, and moreover,
when clients do this, they lose the ability to easily emit diagnostics
on the now-folded nodes.
