When `codeql_platform_select` builds its `select` from a macro invoked in
another workspace (e.g. semmle-code consuming this repo as `@codeql`), a bare
`//misc/bazel:linux_arm64` string key resolves against the consuming repo and
fails with "no such package 'misc/bazel'". Use `Label(...)`, which resolves
relative to this file's own repo, so the key always binds to
`@codeql//misc/bazel:linux_arm64` regardless of the calling workspace.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: c5c5b0bf-4afa-468c-b2dd-197d80932b4b
`posix` sets the shared value for both `linux` and `macos`. It is mutually
exclusive with either of them and fails if supplied together with `linux`
or `macos`.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: c5c5b0bf-4afa-468c-b2dd-197d80932b4b
- codeql_pack docstring: include `linux-arm64` in the exhaustive list of
values the `{CODEQL_PLATFORM}` placeholder expands to (both mentions).
- codeql_platform_select: only fall back to `otherwise` on `None`, not on
any falsey value, via a small `_or_otherwise` helper, matching the
documented `None` defaults.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: c5c5b0bf-4afa-468c-b2dd-197d80932b4b
CODEQL_PLATFORM is OS-only today (linux->linux64, macos->osx64,
windows->win64). ELF has no fat-binary equivalent, so Linux arm64 needs
its own string. Add `linux-arm64` for os:linux AND cpu:arm64 while
keeping every existing string byte-identical.
- Add a public `//misc/bazel:linux_arm64` config_setting (os:linux +
cpu:arm64).
- Turn `os_select` into `codeql_platform_select`, a full selector over
the four CodeQL platforms (`linux64`, `linux_arm64`, `osx64`, `win64`,
plus `otherwise`), working in both macro (select) and rule
(target_platform_has_constraint) contexts. There is deliberately no
fallback between the two Linux slots.
- Re-express `os_select` as a thin OS-only wrapper around it (Linux maps
to both `linux64` and `linux_arm64`), so its existing swift/xcode
callers keep working unchanged.
- Add an `_arm64_constraint` entry to OS_DETECTION_ATTRS.
- Drive the platform string from `codeql_platform_select` in pkg.bzl's
`_detect_platform` and defs.bzl's `codeql_platform`.
macOS keeps osx64 for both arch slices (universal binary): the
linux_arm64 key requires both constraints, so the OS discriminator
dominates. The new branch is dormant on existing CI (no job builds
linux-on-arm64), so all current configs produce byte-identical outputs.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: c5c5b0bf-4afa-468c-b2dd-197d80932b4b
Adds a few tests that validate that higher-order functions are parsed
correctly into the commonAST representation.
Also removes a redundant assignment to `ctx.in_function_type` that
happend after all translations had taken place (and so nothing would
actually read this field).
The extractor shells out to a separate `swift-syntax-parse` binary, but
nothing placed it in the extractor pack, so a shipped Swift extraction
failed at the first spawn. Package it next to the extractor, the same
way `//swift/extractor` ships its Swift-linked binary: a small wrapper
points the dynamic loader at its own directory and execs the real
binary, whose Swift runtime libraries travel alongside it.
- `swift-syntax-parse.sh`: wrapper that sets `LD_LIBRARY_PATH` /
`DYLD_LIBRARY_PATH` to its directory and execs
`swift-syntax-parse.real`
(mirrors `swift/extractor/extractor.sh`).
- `runtime.bzl`: a `swift_runtime_libs` rule that selects just the Linux
Swift runtime shared objects (`usr/lib/swift/linux/*.so`) out of the
full toolchain, so only they — not the whole toolchain — travel with
the binary.
- `swift-syntax-rs/BUILD.bazel`: the `rust_binary` becomes
`swift-syntax-parse.real`
and carries the runtime libraries as runfiles on Linux; a `sh_binary`
(`swift-syntax-parse`) is the wrapper; `codeql_pkg_runfiles` flattens
the three (wrapper, real binary, runtime) into one directory.
- `BUILD.bazel`: ship that group under `tools/{CODEQL_PLATFORM}` next to
the extractor, on the platforms where swift-syntax builds
(Linux/macOS).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
`languages::swift::adapter` embeds the swift-syntax node-types schema
with `include_str!("../../../swift_node_types.yml")`, but the file was
never listed in the extractor's Bazel `compile_data`. The `cargo` build
finds it on disk, so this went unnoticed, but the sandboxed Bazel build
cannot see it and fails to compile the extractor. List it alongside
`ast_types.yml`.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Two fixes prompted by review of the swift-syntax switch-over.
Parser resolution (`parse.rs`): `parse_bin` now resolves the
`swift-syntax-parse` executable in priority order — the
`CODEQL_EXTRACTOR_UNIFIED_SWIFT_SYNTAX_PARSE` override, then a copy next
to the extractor executable (as a shipped extractor pack lays it out:
`tools/<platform>/{extractor,swift-syntax-parse}`), then a
bare `PATH` lookup. This lets a packaged extractor find its parser with
no environment setup. (Bundling the binary into the pack, together with
its Swift runtime, is a separate follow-up.)
Corpus test guard (`corpus_tests.rs`): `parser_available` previously
treated *any* parser error as "unavailable" and skipped the entire
corpus suite, so a parser that was present but crashed or emitted
invalid JSON would silently skip the exact regressions the suite exists
to catch. It now uses the new `binary_available`, which reports whether
the *executable* can be launched (false only when it cannot be found,
e.g. no Swift toolchain); a launchable-but-failing parser makes the
suite run and fail.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
`swift-syntax-rs` is a workspace member, so its build script runs on a
plain `cargo check`/`fmt`/`clippy` at the repo root. Previously it
panicked when `swift build` could not be run, breaking those Swift-free
workflows for anyone without a Swift toolchain.
Instead, when `swift build` cannot be spawned, emit a `cargo:warning`
and skip the link directives rather than panicking. `cargo
check`/`fmt`/`clippy` don't link, so they keep working; only `cargo
build`/`cargo test` then fail, at link time — which is fair, since those
genuinely need Swift (and CI builds go through Bazel). A Swift toolchain
that is present but whose build fails is still surfaced as a hard error.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Regenerate `types/property-with-getter-and-setter`, whose mapped AST now
differs from the tree-sitter output: the backing `private var _v`
retains its `private` modifier (`modifier "var"` + `modifier
"private"`), whereas the tree-sitter path dropped it (its
`visibility_modifier` node carried no text). The swift-syntax
front-end preserves the modifier, so the mapped AST is strictly richer
here.
The raw (second) section is regenerated to the swift-syntax AST like the
other cases; the mapped (third) section gains the retained `private`
modifier.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Now that the Swift front-end is swift-syntax, regenerate the second (raw
parse tree) section of the corpus `.output` files to hold the
swift-syntax AST the adapter builds, instead of the old tree-sitter
parse tree.
These 98 cases map to a byte-for-byte identical mapped AST (the third
section), so only their raw section changes — the mapping rules were
ported to produce the same output. The one case whose mapped AST differs
(`types/property-with-getter-and-setter`) is handled separately.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
