In C++20, types that declare or delete their default/copy/move constructors are no longer aggregates, so the aggregate uses of these types will not compile under C++20. Adding them fixes this, without affecting older language modes.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
Protocol composition types such as `P & Q` are similar to nested types
like `A.B` because the innermost type syntax node at the given position
doesn't cover the whole type. Adjust by looking back up the tree.
This all feels like a hack, and there should be a better way.
While here, fix the source ranges passed in to create
`CompositionTypeRepr`. We were tripping assertions due to missing
source-location information.
Bridge the simple type attributes like `@autoclosure` into an
`AttributedTypeRepr`. We don't validate the arguments, and we don't
handle more complicated attributes like `@convention(c)` just yet.
There is a modeling difference between the swift-syntax tree and the
C++ type representation (TypeRepr) that is a little odd here, so we
end up parsing the ellipsis on the C++ side rather than looking "up"
the syntax tree to find it.
C stdlib headers are part of "Darwin"/"Glibc" clang module.
If a Swift file imports a bridging headers and that has '#include'
C stdlib headers, Swift compiler implicitly imports "Darwin"/"Glibc"
overlay modules. That violates dependency layering. I.e. Compiler
depends on Darwin overlay, Darwin overlay is created by the compiler.
rdar://107957117
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
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.
pack expansion type reprs.
Classic variadic parameters still use the postfix ellipsis syntax, and
pack expansion types now use a prefix 'repeat' keyword.
Rather than set closure discriminators in both the parser (for explicit
closures) and then later as part of contextualizing closures (for
autoclosures), do so via a request that sets all of the discriminators
for a given context.
Implement an ASTGen operation to bridge swift-syntax diagnostics, as
produced by the parser, operator folding, and macros, over to the C++
diagnostic engine infrastructure. Use this to wire up macro expansion
diagnostics.
