feat(promql): scalar operand for BinaryOp — vector-op-scalar lowering (#35) - #77
Merged
Merged
Conversation
…#35) `<vector> op <scalar>` — threshold alerts (`v > 10*1024*1024`), unit conversions (`rate(m[5m]) * 100`) — did not lower: BinaryOp required both operands to be vectors and the front end rejected bare number literals. This was the single biggest real-world blocker (~822/949 of the alerts corpus). Adds a `Scalar(f64)` leaf to the L2 relational tree and the L3 canonical IR. A number literal (and a constant-folded scalar expression like `10*1024*1024` / `24 * 3600`) lowers to `Scalar`; a `BinaryOp` operand folds to a scalar when it has no vector selector, else walks as a vector. The BinaryOp output schema follows the vector side (a scalar contributes no labels); `num_expr` now constant-folds arithmetic (also lets `topk(2+1, …)` work). Impact: awesome-prometheus-alerts corpus coverage jumps from 13 to 863/949 lowered. Flipped `scalar_literal_operand_is_rejected__GAP` and `scalar_threshold_comparisons_are_rejected__GAP` into passing tests; raised the corpus ratchet 12 -> 800. Vector-vector BinaryOp and all other paths unchanged. Full workspace suite green; clippy --all-targets clean. Co-Authored-By: Claude Opus 4.8 (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
1 participant
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.
Closes #35 — the single biggest real-world lowering blocker.
What
<vector> op <scalar>— threshold alerts (v > 10*1024*1024), unit conversions (rate(m[5m]) * 100) — didn't lower:BinaryOprequired both operands to be vectors and the front end rejected bare number literals.How
Scalar(f64)leaf in the L2 relational tree and the L3 canonical IR.10*1024*1024→10485760,24 * 3600→86400) — lowers toScalar. ABinaryOpoperand folds to a scalar when it contains no vector selector, otherwise walks as a vector.BinaryOpoutput schema now follows the vector side (a scalar contributes no labels).num_exprgained constant-folding of scalar arithmetic (also makestopk(2+1, …)work).Impact
awesome-prometheus-alerts corpus: lowered 13 → 863 / 949 (rejected 86, unparseable 0). The dominant
<vector> <cmp> <scalar>shape now lowers.Flipped
scalar_literal_operand_is_rejected__GAP+scalar_threshold_comparisons_are_rejected__GAPinto passing conformance/corpus tests; raised the corpus coverage ratchet 12 → 800. Vector-vectorBinaryOpand every other path unchanged. Full suite green (29 binaries), clippy clean.🤖 Generated with Claude Code