fix: support :bind in SOSL WITH DIVISION clause#89
Merged
Conversation
…SL WITH clauses
Two related grammar gaps around `:expr` bind variables:
1. `fieldExpression` only accepted `fieldName` or `soqlFunction` as the
left operand. Salesforce permits a bind expression too, e.g.
`WHERE :A.TYPE INCLUDES ('Customer - Direct')`. Added
`boundExpression` as a third alternative.
2. `soslWithClause` hard-coded `StringLiteral` for `WITH DIVISION`,
`WITH NETWORK`, `WITH PRICEBOOKID`, and `WITH METADATA`. Each now
accepts `StringLiteral | boundExpression` so bind variables can be
used, e.g. `WITH DIVISION = :myString`.
Both cases are documented in the Salesforce "SOQL and SOSL Apex
Variables" guide.
Fixes #44
Tested each of the originally-reported grammar extensions against a real Apex org via `sf apex run`: - SOQL `:bind` on the LHS of a WHERE comparison (e.g. `:A.TYPE INCLUDES (...)`): Apex compiler rejects it, both inline and via `Database.queryWithBinds` (`System.QueryException: unexpected token: ':'`). The example in the Salesforce Apex Developer Guide appears to be a non-working snippet (semantically it would reduce to a comparison between two constants). Binds on the RHS inside value lists already parse today via the existing `value` rule — no change needed. - SOSL `WITH NETWORK|PRICEBOOKID|METADATA = :bind`: all three rejected by the Apex compiler. Only literal StringLiteral is accepted. - SOSL `WITH DIVISION = :bind`: accepted by the Apex compiler (documented, verified). Keeping only the DIVISION change so the grammar stays aligned with what the Apex compiler actually accepts, consistent with prior corrections (e.g. 3.1.0 modulus removal, 3.5.0 do-while tightening).
Contributor
|
@codex review |
|
Codex Review: Didn't find any major issues. Keep it up! ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
nawforce
approved these changes
Apr 23, 2026
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
2 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.
Summary
Partially fixes #44. Extends
soslWithClausesoWITH DIVISIONacceptsStringLiteral | boundExpression, allowing:This is the only part of #44 that corresponds to a real parser gap. See the discussion below for why the rest was dropped.
Why not the other reported cases?
The #44 report included two examples transcribed from the Salesforce Apex Developer Guide. Both were tested against a real Apex org using
sf apex run:SOQL
WHERE :A.TYPE INCLUDES (...)— bind on LHS of WHERE. Apex compiler rejects it inline (Unexpected token ':') and viaDatabase.queryWithBinds(System.QueryException: unexpected token: ':'). Semantically it would reduce to a comparison between two constants, so it's unlikely to be intended behaviour. Bind on the RHS (INCLUDES (:c)) was already handled by the existingvaluerule — no change needed.SOSL
WITH DIVISION = :bind— accepted by Apex. This is the change in this PR.SOSL
WITH NETWORK|PRICEBOOKID|METADATA = :bind— all three rejected by the Apex compiler. Literal-only.Keeping the grammar aligned with the Apex compiler rather than with the (evidently flawed) docs example, consistent with prior corrections like 3.1.0's modulus removal and 3.5.0's do-while tightening.
Test plan
npm test— 75/75 (74 baseline + 1 newtestBindVarInDivisionClause)mvn test— 74/74 (73 baseline + 1 matching Java test)npm run lintcleanpre-releaseorg viasf apex run:WITH DIVISION = :bindcompiles; all other reported variants are rejected by the Apex compiler