Swift.org macOS toolchains store their runtime libraries under
usr/lib/swift/macosx/ (Apple's SDK name), not usr/lib/swift/macos/
(the Bazel @platforms//os:macos name). rules_swift 4.0.0-rc4's
_swift_unix_linkopts_cc_info uses the latter, causing -L to point at
a non-existent directory and ld to fail with undefined
swiftCompatibility{56,Concurrency,Packs} symbols on macOS.
Rewrite platform_lib_dir to `usr/lib/swift/macosx` on the macOS branch
of the existing patch so the -L / -Wl,-rpath resolve to a real dir
that already gets materialized into the sandbox via swift_tools'
`additional_inputs = glob(["usr/lib/swift/**", ...])`.
Also gathers these into a separate side-channel during the initial AST
construction. That way, we don't encounter these as weird extra nodes
while running yeast.
Introduces new yeast types for `Point`s and `Range`s (corresponding to
the tree-sitter equivalents), since it seemed silly to have
`swift-syntax-rs` pull in `tree-sitter` just to have those types
available.
This _does_ mean there is a slight overhead in the shared extractor when
converting between these types, but I think this is negligible.
Adds a preliminary mapping that decodes the JSON into the yeast AST. The
JSON AST itself is still very verbose, but it would be useful to see if
it actually contains all of the things we want it to contain.
Adds an initial prototype of an interface from Rust to Swift, which
enables us to use the `swift-syntax` package for parsing.
At present, the parsed AST is passed between Swift and Rust as a JSON
string.
Turns out, `(_)` would match both named and unnamed nodes, as we never
checked the value of the `match_unnamed` field. This is the real reason
why the final catch-all rule we removed in the last commit was
superfluous -- unnamed nodes were being caught by the penultimate rule
instead (and mapped to `unsupported_node`).
Having fixed the bug, we now (correctly) get errors due to unmatched
unnamed nodes in the input. To fix this, we change the catch-all rule to
match unnamed nodes as well. This restores the previous behaviour
exactly.
At some point, we should find a better way to handle unnamed nodes, as
it seems wasteful to map these to `unsupported_node` (since we in
practice only use them for their string content). Perhaps we should not
attempt to translate unnamed nodes at all?
