These are currently added implicitly by the compiler in the context of
`if`/`switch` expressions. In the future, there might be explicit
`then <expr>` statement useful for cases where one would like to add
more than one statement in the branch, to mark what value to actually
use.
See https://forums.swift.org/t/pitch-multi-statement-if-switch-do-expressions/68443
They only appear in an intermediate AST and disappear as soon as the
macro is expanded.
The only way to get these in is to construct an "incorrect" AST, e.g.:
```
let x = #does_not_exist() // MacroExpansionExpr
struct S {
#does_not_exist() // MacroExpansionDecl
}
```
This simplifies several instances of metaprogramming by leveraging
[constraints and concepts from C++20][1]. This:
* gets rid of `std::enable_if` by usage of `requires`, making it more
readable and yield better compiler messages.
* uses `requires` instead of `static_assert` to enforce `TrapLabel`
typing
* simplifies all compile-time tests for validity of a given expression
* uses some standard library concepts where possible
* generalizes and simplifies `SwiftLocationExtractor`
Notice that in order to use the `std::derived_from` concept, `virtual`
inheritance had to be added to the label tags, because diamond
inheritance is a problem otherwise. That's because
`std::derived_from<T, U>` requires that `T*` be convertible to `U*`,
which is false if there are multiple non-virtual inheritance paths from
`U` to `T`. As tags never get actually instantiated, there is no runtime
performance penalty in using `virtual` inheritance.
[1]: https://en.cppreference.com/w/cpp/language/constraints
Our mangler is split in two version:
* `SwiftTrapMangler`, with the same behaviour as the previous
`SwiftMangler`, constructing mangled names with trap label references
* `SwiftRecursiveMangler` that replaces trap label references with
recursive calls to its own `mangle` functions, effectively rolling out
the entire chain of references
The latter is used to create lazy trap file names. Hashing is used to
avoid excessively long filenames.
* visiting now happens in a later stage than fetching labels. While
fetching a list of entities to be visited is created, and then acted
upon in actual extraction. This partially flattens the recursive
nature of `fetchLabel` into a loop inside `SwiftVisitor::extract`.
Recursion in `fetchLabel` will only happen on labels fetched while
naming an entity (calling into `SwiftMangler`).
* The choice whether to name a declaration or type has been moved from
the translators to `SwiftMangler`. Acting on this choice is contained
in `SwiftDispatcher::createLabel`.
* The choice whether to emit a body of a declaration has been moved from
`DeclTranslator` to the dispatcher. This choice is also contained in
`SwiftDispatcher::createLabel`.
* The simple functionality of the `LabelStore` has been moved to the
`SwiftDispatcher` as well.
