Add facts and fact_filter to Piranha rules - #780
Merged
ketkarameya merged 5 commits intoMar 12, 2026
Conversation
|
|
Introduces two new features:
**Facts**: Rules can record structured String->String metadata about matched
nodes without modifying code. Facts are associated with the matched node's range,
stored per-file in SourceCodeUnit, and included in PiranhaOutputSummary output.
When a rewrite overlaps a fact's range the fact is marked voided; rewrites that
precede a fact's range shift its byte offsets.
**Fact filter**: Rule filters gain a fact_filter field. A filter with a non-empty
fact_filter only passes when at least one non-voided recorded fact in the file
contains all the specified key-value pairs. This lets rewrite rules be gated on
information recorded by earlier fact rules.
TOML usage:
[[rules]]
name = "record_api"
query = "..."
replace_node = "call"
fact = { type = "deprecated", method = "@name" }
[[rules.filters]]
fact_filter = { type = "deprecated" }
Also adds 11 unit tests and 2 integration tests covering: basic fact recording,
@tag substitution, multi-match ordering, voiding by rewrite, byte-offset shifting,
two facts on the same range, fact_filter blocking/allowing rewrites, and
voided-fact semantics end-to-end.
Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
ketkarameya
force-pushed
the
feature/facts-and-fact-filter
branch
from
March 12, 2026 06:52
614ceae to
5947b61
Compare
danieltrt
reviewed
Mar 12, 2026
|
|
||
| /// Checks if a rule is a `fact` rule i.e. it records facts without rewriting code | ||
| pub(crate) fn is_fact_rule(&self) -> bool { | ||
| !self.fact().is_empty() |
Collaborator
There was a problem hiding this comment.
if a user sets both fact and replace in TOML, this check fires first and the replace is silently ignored. should validate() reject rules that have both?
Collaborator
Author
There was a problem hiding this comment.
I think rules with both is weird. Do u mean, we want toads facts to the rewritten stuff ? In that case we can always have a self edge to add the fact
Collaborator
There was a problem hiding this comment.
Im just thinking whether we should panic when we read a rule that;s supposed to generate facts, but then sets rewrite?
|
|
||
| /// Shift byte offsets by `delta` after a preceding edit. | ||
| /// Point (row/col) offsets are not adjusted since we don't have source code available here. | ||
| pub(crate) fn shift_range(&mut self, delta: isize) { |
Collaborator
There was a problem hiding this comment.
this shifts byte offsets but leaves start_point / end_point stale. since Range exposes both, consumers could read wrong row/col from shifted facts, right?
- validate(): reject rules that set both `fact` and `replace` — they are mutually exclusive. Previously the fact branch silently won and `replace` was ignored; now a clear error is surfaced at rule construction time. - shift_range(): was only updating start_byte/end_byte but left start_point and end_point stale, so consumers reading row/col from a shifted fact would get incorrect values. Now propagates row/col deltas from the InputEdit: facts on a later row shift by row_delta; facts on the same row as the edit end also shift their column. Adds two new tests: - test_validate_rejects_fact_and_replace_together - test_fact_shift_updates_row_col_points Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
danieltrt
approved these changes
Mar 12, 2026
danieltrt
left a comment
danieltrt
left a comment
Collaborator
There was a problem hiding this comment.
LGTM overall, cargo fmt is failing
Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
ketkarameya
enabled auto-merge (squash)
March 12, 2026 20:44
The hook ran `cargo clippy --fix --allow-staged` which refused to apply fixes whenever any file had unstaged changes. Adding `--allow-dirty` lets it proceed regardless of unstaged changes in other files. Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Introduces two new features:
Facts: Rules can record structured String->String metadata about matched nodes without modifying code. Facts are associated with the matched node's range, stored per-file in SourceCodeUnit, and included in PiranhaOutputSummary output. When a rewrite overlaps a fact's range the fact is marked voided; rewrites that precede a fact's range shift its byte offsets.
Fact filter: Rule filters gain a fact_filter field. A filter with a non-empty fact_filter only passes when at least one non-voided recorded fact in the file contains all the specified key-value pairs. This lets rewrite rules be gated on information recorded by earlier fact rules.
TOML usage:
[[rules]]
name = "record_api"
query = "..."
replace_node = "call"
fact = { type = "deprecated", method = "@name" }
[[rules.filters]]
fact_filter = { type = "deprecated" }
Also adds 11 unit tests and 2 integration tests covering: basic fact recording, @tag substitution, multi-match ordering, voiding by rewrite, byte-offset shifting, two facts on the same range, fact_filter blocking/allowing rewrites, and voided-fact semantics end-to-end.