Rename the sha256 attributes (and matching canonical_ids) to a single
scheme across all platforms: <os>_x64 / <os>_arm64. This replaces the
inconsistent sha256_linux (no suffix), sha256_macos_intel and
sha256_macos_arm.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: c6404a7a-35d7-4294-b3b6-9231ca15ef25
repository_ctx.os.arch reports the lower-cased Java os.arch property,
which is "aarch64" on Linux arm64 — same as the macOS branch below.
Drop the redundant "arm64" alternative.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: c6404a7a-35d7-4294-b3b6-9231ca15ef25
The `ripunzip_archive` repository rule downloaded a prebuilt ripunzip for
the host platform, but the Linux branch was hardcoded to the amd64 deb,
so on an arm64 Linux host it would fetch an x86 binary. Switch on
`repository_ctx.os.arch` (mirroring the macOS branch) to select the
arm64 deb, which ripunzip publishes for the pinned version.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: c6404a7a-35d7-4294-b3b6-9231ca15ef25
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
Pure deletion of the generated `BUILD.<crate>.bazel` files for the
crates the previous commit removed from `defs.bzl` and `MODULE.bazel` —
`cc`, `tree-sitter-generate`, `tree-sitter-language` and their
transitive closure (bindgen, clang-sys, phf, rquickjs, …). Nothing
instantiates the corresponding repositories any more, so the files are
dead.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Dropping the tree-sitter-swift crate removed the last consumer of the
tree-sitter grammar-generation dependencies, but the vendored Bazel deps
still listed them, so `defs.bzl` disagreed with the Cargo manifests:
`unified/extractor` was still given `tree-sitter` and
`tree-sitter-embedded-template`, and
`unified/extractor/tree-sitter-swift` remained as a package entry.
Regenerated with
`misc/bazel/3rdparty/update_tree_sitter_extractors_deps.sh`,
which drops `cc`, `tree-sitter-generate` and `tree-sitter-language`
along with their transitive closure. `tree-sitter` itself stays, as the
Ruby and QL extractors still use it.
This commit carries the regenerated `defs.bzl` and `MODULE.bazel`; the
vendored BUILD files for the dropped crates are deleted in the following
commit.
This was drift rather than breakage — the extra entries were simply
unused, so the build worked either way.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Wrapping an optional capture in a node meant building the wrapper inside
an `Option::map`, which buried the shape of the output in a closure:
(break_expr label: {lbl.map(|l| tree!((identifier #{l})))})
A field's value can now be marked with `?` instead. If a `#{expr}`
anywhere beneath it interpolates an absent value, the subtree is
abandoned and the field is left unset:
(break_expr label: (identifier #{lbl})?)
The marker follows the value, as quantifiers do in the query language
(`label: _? @@lbl`). Absence propagates through as many levels as
necessary, and a nested `?` catches first, so an inner absent value need
not discard the outer node.
Only `#{expr}` propagates absence, since it supplies a node's content:
with no value there is no leaf to build. A `{expr}` splice supplies
children, where yielding nothing already leaves the field unset, so `?`
is rejected on one. Outside a `?`, interpolating an `Option` with
`#{expr}` remains a compile error, keeping the choice between leaving a
field unset and unwrapping explicit; `YeastDisplay` now carries an
`on_unimplemented` note pointing at the new syntax.
Inside a fallible field, interpolations route through a new
`MaybeYeastValue` trait, whose impls are enumerated rather than blanket
for the same coherence reason `YeastDisplay`'s are.
Codegen outside a `?` is unchanged, so `tree!` and `trees!` keep their
return types. Converting the ten `Option::map` sites in the Swift rules
leaves the corpus byte-identical; four captures become `@@` now that
their values are only ever interpolated.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Adds rules for mapping things like `=` and `as!` to `infix_operator`s,
so that they are present in the output (which for unresolved operators
expects an alternating sequence of values and `infix_operator`s).
For ternary operators, we expand this into _two_ unresolved infix
operators, `?` and `:` respectively.
Add corpus test cases that witness Swift constructs the swift-syntax
mapping does not yet handle, so they map to `unsupported_node` (or, for
unfoldable operator chains, `unresolved_operator_sequence`). These
document the current behaviour and give us a place to observe the diff
when each construct is eventually supported.
The cases are placed alongside the feature they exercise:
- functions: `inout` parameter types and `&`-prefixed inout arguments.
- expressions: key paths, generic specialization in expression position
(`Array<Int>()`), `copy`/`consume` expressions, and `unsafe`
expressions.
- operators: unresolved operator sequences (pointwise operators the
parser cannot fold), custom postfix operators, and partial ranges.
- control-flow: `fallthrough`, `defer`, and `discard` statements.
- types: `actor` declarations, inline array types (`[3 of Int]`),
function-type attributes (`@convention(c)`, `@Sendable`), noncopyable
(`~Copyable`) types, and conditional compilation in a class body.
- literals: the `#line` magic literal.
The conditional-compilation case is worth calling out because it
swallows members: swift-syntax reports a structured `ifConfigDecl` whose
branches hold ordinary member items, but with no rule for it the whole
`#if` block collapses into a single `unsupported_node`, so the
declarations inside are not extracted at all.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Pure deletion of the files the previous commit left unreferenced:
- the vendored `unified/extractor/tree-sitter-swift` crate — grammar,
generated parser tables, editor queries and Node bindings;
- `scripts/regenerate-grammar.sh`, which regenerated those tables from
the grammar;
- the `rules_macro_smoke` test, which type-checked the `rules!` macro
against the crate's `node-types.yml` and so cannot outlive it.
The extractor now builds with no Swift grammar and no Swift toolchain;
the Swift dependency lives solely in the separate `swift-syntax-parse`
binary.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
With the Swift front-end fully switched to swift-syntax, nothing links
the tree-sitter Swift grammar any more. Remove every reference to it;
the vendored crate itself is deleted in the following commit, so that
this one shows only what actually changed.
- Drop `unified/extractor/tree-sitter-swift` as a workspace member, path
dependency and BUILD.bazel dependency.
- Drop the now-unused `tree-sitter` and `tree-sitter-embedded-template`
direct dependencies from the extractor (neither is referenced any
longer; the tree-sitter runtime is still pulled in transitively where
the shared extractor needs it).
- Rewrite the "Swift Parser" section of `AGENTS.md`, which still pointed
at `grammar.js` and `node-types.yml`, to describe `swift-syntax-parse`
and the hand-maintained `swift_node_types.yml`, and note that the
tests need the parser binary.
The mapping's comments also explained many rules by how the tree-sitter
path had behaved. That is now of historical interest only, so each is
restated in terms of swift-syntax and the target AST alone — no rule
changes, and the corpus is unaffected. Two were more than stylistic:
- The `subscriptCallExpr` rule and its corpus case said the parser
reports `xs[0]` and `xs(0)` identically. swift-syntax distinguishes
them, so the collapse to `call_expr` is now purely ours, and a
dedicated `subscript_expr` would need only a schema addition and a
remap.
- `discardAssignmentExpr` mapped to `name_expr` "because tree-sitter
treated `_` as a name". The standing reason is that the target AST has
no expression-level discard — only `ignore_pattern`, which is a
pattern.
References to tree-sitter's *node model* are kept: yeast is built on it,
so `adapter.rs` still explains named/anonymous nodes, `extra` tokens and
byte-offset conventions in those terms.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Map a nominal type's inheritance clause (`class C: Base, Proto`, and
likewise for enum/struct/protocol/extension) to `base_type` children on
the `class_like_declaration`, one per inherited type. The tree-sitter
path dropped these (no corpus target had a `base_type`) and the mapping
matched that for parity; swift-syntax exposes the clause cleanly.
Adds a focused `class-with-multiple-base-types` corpus case and updates
`class-inheritance` to witness the restored base types.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Map a generic type applied with explicit arguments (`Set<Int>`,
`Dictionary<String, Array<Int>>`) to a `generic_type_expr` whose `base`
is the type name and whose `type_argument`s are the structured,
recursively-mapped arguments — the same shape the sugared `?`/`[]`/`[:]`
types already desugar to.
Previously the whole application was kept opaquely as a
`named_type_expr` whose name was the raw source text, matching the
tree-sitter path for corpus parity.
Adds a focused `generic-type-arguments` corpus case (multiple and nested
arguments) and updates `set-literal` to witness the structured
arguments.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Emit a parameter's declared type on the mapped `parameter` node. The
tree-sitter path dropped it — its untyped-parameter rule was ordered
before the typed one and shadowed it — and the mapping matched that for
corpus parity; swift-syntax models the type as a required
`functionParameter.type`, so emitting it is a correctness improvement.
The existing function-parameter corpus cases (and the initializer cases
from the previous commit) witness the restored types.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Emit an initializer's parameters on the `constructor_declaration`,
captured from the `initializerDecl` signature (as for `functionDecl`).
The tree-sitter path dropped them -- its positional `(parameter)*`
capture missed the field-attached parameters -- and the mapping matched
that for corpus parity; swift-syntax exposes them cleanly, so emitting
them is a correctness improvement.
Adds a focused `constructor-with-parameters` corpus case and updates
`class-with-initializer` to witness the restored parameters.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
