* do not mention any more that one might make analysis happen on Linux with
advanced setup
* say that outright Swift analysis is only supported on macOS, not just
autobuild.
* emit the error diagnostics even for traced builds, not only for autobuilds
(by using a dummy `extractor` executable).
Previously, we were using 8.0.0rc1.
In particular, this upgrade means we need to explicitly
import more rules, as they've been moved out of the core bazel repo.
This encapsulate arch specific logic, local installation and separation
of zip files into generic and arch-specific parts as required by the
internal build.
This introduces tooling and enforcement for formatting bazel files.
The tooling is provided as a bazel run target from
[keith/buildifier-prebuilt](https://github.com/keith/buildifier-prebuilt).
This is used in a [`pre-commit`](https://pre-commit.com/) hook for those
having that installed. In turn this is used in a CI check. Relying on a
`pre-commit` action gives us easy checking that buildifying did not
change anything in the files and printing the diff, without having to
hand-roll the check ourselves.
This enforcement will make usage of gazelle easier, as gazelle itself
might reformat files, even outside of `go`. Having them properly
formatted will allow gazelle to leave them unchanged, without needing
to configure awkward exclude directives.
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 fetches the resource directory directly from the released
toolchains, allowing us to stop prebuilding and assembling them.
Moreover insertion of our resource directory is moved to the lua
tracing configuration (solving a `TODO`) and enhanced. Now all options
that start with the original resource directory (either explicit or
implied) are redirected to our resource directory.
This solves a problem where `-I <original resource dir>/some/path` was
passed to the extractor and did not work.
This works around the 5.9 linux compatibility problem by including the
`PackageDescription` swift modules in the in-dist toolchain. Copying the
toolchain and fixing the `-I` flag was not enough as for some reason
compilation of `PackageDescription.swiftinterface` was causing a crash
in the SIL pass. We work around that by pre-compiling those modules
during the build and including `.swiftmodule` files in the resource
directory.
TODO (apart from testing):
* the libraries included in the macOS toolchain are now fat (they were
intel only before), occupying more space. We should see if we need to
trim them down.
* there might be other swiftinterface files causing problems on linux
lurking around...
* if we go with this, we can simplify and trim down the prebuilding we
do leaving out the resource directory.
* `variables` under `CaseStmt` are now AST children, which solves
orphan `VarDecl`s in that case
* reordered `CaseStmt` AST children to be `labels > variables > body`
(was `body > labels`)
* made `NamedPattern::getVarDecl` an extracted property instead of
`getName`
* The above led to duplicate DB entities because of a quirk in the
Swift compiler code. This is solved by tweaking the extraction of
`variables` under `CaseStmt` to not use `getCaseBodyVariables`.
