Flexible StandardQueryParser misses -0.0 documents for exclusive float/double bounds

With the flexible StandardQueryParser and a PointsConfig of type Float or Double, an exclusive bound at zero skips the opposite-signed zero. PointRangeQueryNodeBuilder makes an exclusive bound inclusive with Math.nextUp / Math.nextDown, which step in IEEE order, where -0.0 equals +0.0; FloatPoint and DoublePoint order values like Float.compare / Double.compare, where -0.0 is a separate value just below +0.0. So the natural f:[* TO 0} ("f < 0") is built as f:[-Infinity TO -1.4E-45] and misses documents holding -0.0, which f:[0 TO *] excludes as well. LUCENE-7594 fixed the same pitfall in the core point classes in 2016 and added the FloatPoint/DoublePoint.nextUp/nextDown helpers, but the parser still calls Math.*. Silent, deterministic, any index size, in every release checked since 6.0.0.

1. The syntax parser records {/} and </> as exclusive flags; f<0 becomes [* TO 0} (StandardSyntaxParser.jj:751-756).
2. PointRangeQueryNodeProcessor parses each bound with the configured NumberFormat and converts it with floatValue() (:118-120) or doubleValue() (:115-117). The literal 0 becomes +0.0; an open bound * stays null.
3. PointRangeQueryNodeBuilder.build, Float branch (:97-113): an open bound becomes -Infinity or +Infinity (:99-101, :107-109); then if (minInclusive == false) { lower = Math.nextUp(lower); } (:102-104) and if (maxInclusive == false) { upper = Math.nextDown(upper); } (:110-112); then FloatPoint.newRangeQuery(field, lower, upper) (:113), whose bounds are inclusive. The Double branch repeats it (:119-121, :127-129, :130).
4. Math.nextDown(+0.0) is -Float.MIN_VALUE (-1.4E-45) and Math.nextUp(-0.0) is +Float.MIN_VALUE (1.4E-45): in IEEE order -0.0 counts as zero, so each step jumps over the other zero.

FloatPoint.nextUp/nextDown (FloatPoint.java:48-70) and the DoublePoint ones exist for exactly this: "Return the greatest float that compares less than f consistently with Float#compare. The only difference with Math#nextDown(float) is that this method returns -0f when the argument is +0f."

One document with f = -0f and d = -0d: f:[* TO 0} and f<0 parse to f:[-Infinity TO -1.4E-45], 0 hits; d:[* TO 0} and d<0 to d:[-Infinity TO -4.9E-324], 0 hits; f:[0 TO *], f>=0 and d:[0 TO *] also 0 hits. On four documents (-1, -0.0, +0.0, 1), f:{-0.0 TO *] parses to f:[1.4E-45 TO Infinity] and returns only 1, missing +0.0, and f:[* TO 0} OR f:[0 TO *] misses the -0.0 document. Only two of the four exclusive cases at zero are wrong: an upper bound at +0.0 and a lower bound at -0.0; {0 TO *] and [* TO -0.0} are right.

• Who. setPointsConfigMap with a Float or Double type. Opt-in, but it is how Lucene's own TestPointQueryParser sets up float fields and the path Luke uses when a user assigns a float or double type to a field (SearchImpl.java:221-240).
• Trigger. x:[* TO 0} or x<0 on an index holding exactly -0.0, which ordinary arithmetic produces: -1 * 0.0, Math.rint(-0.4), Math.ceil(-0.5), Float.parseFloat("-0") and (float) -1e-50 all give -0.0. The mirrored case, {-0.0 TO *] missing +0.0, needs -0.0 typed in the query and is rarer.
• Effect. Silent wrong results: the documents holding exactly the opposite-signed zero are missing; no error; one document shows it; the same with assertions on and off. One numeric value per query, but every document holding it; every other finite bound is exact.
• Seen before, elsewhere. The same symptom was user-visible in another code base: elastic/elasticsearch#22167 (2016, lt 0.0 missing -0.0, in Elasticsearch's own range code, not this parser) is what led to LUCENE-7594.

Oracle: the Float#compareTo order that FloatPoint.newRangeQuery documents, in which -0f < 0f. LuceneTestCase is only the base class; plain IndexWriterConfig and IndexSearcher, so nothing depends on the seed (DEADBEEF and 1234ABCD fail the same way). The query text holds no negative zero.

Regression test: this same class (or its one method added to TestPointQueryParser); it passes with the recommended fix.

cp $REPRO/TestPointRangeExclusiveZeroBound.java $LUCENE/lucene/queryparser/src/test/org/apache/lucene/queryparser/flexible/standard/
cd $LUCENE && ./gradlew :lucene:queryparser:test --tests TestPointRangeExclusiveZeroBound -Ptests.seed=DEADBEEF -Ptests.asserts=true
# assertions off fails the same way: -Ptests.asserts=false

# gradle, stock 645d4fe14a20, -Ptests.seed=DEADBEEF -Ptests.asserts=true (stack trimmed; -Ptests.asserts=false identical)
   >     java.lang.AssertionError: hits of f:[-Infinity TO -1.4E-45] expected:<1> but was:<0>
   >         at __randomizedtesting.SeedInfo.seed([DEADBEEF:5CC102E284EE967E]:0)
   >         at org.apache.lucene.queryparser.flexible.standard.TestPointRangeExclusiveZeroBound.testLessThanZeroMatchesNegativeZero(TestPointRangeExclusiveZeroBound.java:49)

:lucene:queryparser:test (FAILURE): 1 test, 1  failure

# extra context, not the repro: one document with f = -0f and d = -0d, stock main jars
f:[* TO 0}   -> f:[-Infinity TO -1.4E-45]    hits=0
f<0          -> f:[-Infinity TO -1.4E-45]    hits=0
f:[0 TO *]   -> f:[0.0 TO Infinity]          hits=0
f>=0         -> f:[0.0 TO Infinity]          hits=0
d:[* TO 0}   -> d:[-Infinity TO -4.9E-324]   hits=0
d<0          -> d:[-Infinity TO -4.9E-324]   hits=0
d:[0 TO *]   -> d:[0.0 TO Infinity]          hits=0

• The API the builder calls says how. FloatPoint.java:210-213 (DoublePoint.java:210-213 the same), on the 1-D newRangeQuery that the builder calls at :113 and :130: "Ranges are inclusive. For exclusive ranges, pass nextUp(lowerValue) or nextDown(upperValue)" (links to FloatPoint.nextUp/nextDown), and "Range comparisons are consistent with Float#compareTo(Float)".
• Lucene decided this in 2016. #8645 (LUCENE-7594, Adrien Grand, reviewed by Dawid Weiss): "Float/Double points are supposed to be consistent with Double/Float.compare, so +0 is supposed to compare greater than -0. However Math.nextUp/nextDown is not consistent with Double/Float.compare". Listed under 6.4.0 Bug Fixes (lucene/CHANGES.txt:8708-8710). Its commit 18d53a43f7b changed only FloatPoint, DoublePoint, CHANGES and two tests (core TestPointQueries, sandbox TestHalfFloatPoint); nobody mentioned the parser.
• Regression against the replaced path. LUCENE-7089 (#8145) added points to the flexible parser "the exact same way legacy numerics works". On 5.5.5 and on 6.0.0's own legacy path, f:[* TO 0} matches the -0.0 document; on 6.0.0's points path it does not.
• The parser's inclusive forms use the points order. f:[0 TO *] excludes -0.0 and f:[* TO -0.0] includes it; only the exclusive step switches to IEEE order.
• Tests. Core asserts FloatPoint.nextDown(0f) is -0f and nextUp(-0f) is 0f (TestPointQueries.java:2396-2431). TestPointQueryParser.java:57-84 tests only inclusive float/double ranges and single values; no queryparser test uses an exclusive float/double bound.

The strongest case for "intended" (the read-only OpenAI GPT-5.6 review rated it moderate): in Java -0.0 < 0 is false, so leaving -0.0 out of x < 0 follows IEEE arithmetic; the parser docs say only that an exclusive range selects values "excluding boundaries" (StandardQueryParser.java:156) and promise nothing about signed zero; the Math.* calls may encode that choice. That much is true: the parser's docs leave the order of the zeros unstated.

Why it fails: under IEEE order -0.0 equals the boundary 0, so it would have to match f:[0 TO *] / f>=0, and it does not (0 hits). No order of the two zeros explains the parser's results: 4 of 12 probe queries are wrong under either. The code shipped in 6.0.0 together with a FloatPoint javadoc that itself recommended Math#nextUp (added 2016-03-17, a week after the parser code of 2016-03-09), advice withdrawn as a bug in 6.4.0; nothing records a decision to keep IEEE order in the parser. The package docs call the standard package "an example Lucene query parser implementation", but the same file calls StandardQueryParser "the default implementation of a fully fledged query parser".

One fix was validated with gradle in a scratch worktree of 645d4fe14a20; an alternative is described so the issue can answer it up front.

4 changed lines in PointRangeQueryNodeBuilder.java (:103, :111, :120, :128); both classes are already imported. The change the study verifier first wrote.

-        lower = Math.nextUp(lower);
+        lower = FloatPoint.nextUp(lower);
-        upper = Math.nextDown(upper);
+        upper = FloatPoint.nextDown(upper);
-        lower = Math.nextUp(lower);
+        lower = DoublePoint.nextUp(lower);
-        upper = Math.nextDown(upper);
+        upper = DoublePoint.nextDown(upper);

Trade-offs

• Changes results only for an exclusive upper bound at +0.0 and an exclusive lower bound at -0.0, which are wrong today; for every other value the helpers return what Math.* returns.
• Results then match FloatPoint.newRangeQuery used as its javadoc says, and the pre-6.0 numeric path.
• Backport-friendly: the file is the same blob on 9.x, 10.x and main.
• An application that relied on x:[* TO 0} leaving out -0.0 would see those documents appear, which is the documented order.

What the checks validated

• Gradle, scratch worktree of 645d4fe14a20: the repro passes with -Ptests.asserts=true and =false; TestPointQueryParser passes 4 of 4.
• :lucene:queryparser:test, whole module, seeds DEADBEEF and CAFEBABE: SUCCESS, 534 tests (533 + the repro), 1 skipped, 0 failed; checkGoogleJavaFormat, forbiddenApisMain and ecjLintMain pass.
• With the rebuilt builder, f:[* TO 0}, f<0, d:[* TO 0} and d<0 parse to [-Infinity TO -0.0] and find the -0.0 document; f:[0 TO *] is unchanged. Earlier shadow-class runs: the study's six-test class passes 6 of 6, and the tie-break's 12-query probe returns exactly the 5.5.5 results.

Treat -0.0 and +0.0 as one value in every parsed float/double range: widen an inclusive bound at zero to cover both zeros and step an exclusive bound at zero past both.

Trade-offs

Changes inclusive queries that are correct today (f:[0 TO *] would start matching -0.0), makes the parser disagree with FloatPoint.newRangeQuery and newExactQuery, and reverses LUCENE-7594's decision.

Method: formal (an SMT query on the real arithmetic, then executed tests).

• Finder (study experiment on points and BKD query evaluation, 2026-10-22, main 7cecf79523). Float.compare, the JDK's Math.nextUp/nextDown and FloatPoint/DoublePoint.nextUp/nextDown were transcribed statement by statement. The Math.nextUp exclusive-bound equivalence holds for every f except -0 (and +0 for nextDown) and fails exactly there; the FloatPoint helpers satisfy it for every f other than NaN and +Inf (-Inf for nextDown). The parser's Math.* calls were then confirmed with a JUnit. The pitfall itself is the one LUCENE-7594 fixed in core in 2016; what is new is that the parser still has it.
• Verification. An independent study verifier wrote its own six-test JUnit (float and double, both bounds, a partition test and a control) and a 4-line counterfactual patch; the hunt added a one-test minimal repro, a reproducer, a refute review, a second adjudication, a history and a prior-report follow-up (see the checks below).