abhinav-phi opened a new pull request, #68730:
URL: https://github.com/apache/doris/pull/68730
### What problem does this PR solve?
Issue Number: close #68721
Related PR: None
Problem Summary:
`FloatLiteral.uncheckedCastTo(DOUBLE)` did
`Double.parseDouble(String.valueOf(value))` and the
decimal path did `new BigDecimal(Float.toString(value))`. Both go through
the shortest decimal
string that represents the float, which throws away the information BE
keeps: a `FLOAT` column
widened to `DOUBLE` is the exact binary widening of the float32 value, not
the decimal literal
the user typed.
```sql
SELECT CAST(CAST(0.1 AS FLOAT) AS DOUBLE), -- FE fold: 0.1
CAST(CAST(0.1 AS FLOAT) AS DECIMAL(20,10)); -- FE fold: 0.1000000000
-- BE (column path, or SET debug_skip_fold_constant = true):
-- 0.10000000149011612 and 0.1000000015
```
So the same expression evaluated as a constant and as a column produced
different values, which
is what the report shows.
The fix widens in binary: `(double) value` for the `DOUBLE` target and `new
BigDecimal((double) value)`
for the decimal targets. That is exactly what a Float32 -> Float64 cast does
on the BE side, so the
folded literal now equals the executed value. Integral and date targets keep
using
`getValue().toString()` through `FractionalLiteral`/`NumericLiteral` and are
unchanged, so
`CAST(CAST(0.1 AS FLOAT) AS INT)` and friends behave as before.
One existing assertion in `FloatLiteralTest` encoded the old behaviour
(`(float) 234.567 -> 234.567`); it is updated to the widened value
(`(double) (float) 234.567` = `234.56700134277344`), which is what BE
returns for that float.
### Release note
None
### Check List (For Author)
- Test <!-- At least one of them must be included. -->
- [ ] Regression test
- [x] Unit Test
- [ ] Manual test (add detailed scripts or steps below)
- [ ] No need to test or manual test. Explain why:
`FloatLiteralTest` now asserts both reported cases (`0.1` widened to
`DOUBLE`, and
`0.1` cast to `DECIMAL(20,10)` -> `0.1000000015`) plus the corrected
`234.567` expectation.
Red, on `master` with only the test changes applied:
```
[ERROR] FloatLiteralTest.testUncheckedCastTo:181 expected:
<234.56700134277344> but was: <234.567>
[ERROR] Tests run: 66, Failures: 3, Errors: 0, Skipped: 0
```
Green, with the source fix:
```
[INFO] Tests run: 3, Failures: 0, Errors: 0 - FloatLiteralTest
[INFO] Tests run: 2, Failures: 0, Errors: 0 - DoubleLiteralTest
[INFO] Tests run: 2, Failures: 0, Errors: 0 - DecimalLiteralTest
[INFO] Tests run: 2, Failures: 0, Errors: 0 - CompareLiteralTest
[INFO] Tests run: 23, Failures: 0, Errors: 0 - CastTest
[INFO] Tests run: 1, Failures: 0, Errors: 0 - ConstantProjectionFoldingTest
[INFO] Tests run: 4, Failures: 0, Errors: 0 - NumericArithmeticTest
[INFO] Tests run: 2, Failures: 0, Errors: 0 -
org.apache.doris.analysis.FloatLiteralTest
```
Command (the project's own flags, from `run-fe-ut.sh`):
```
mvn test -pl fe-core -am -Dcheckstyle.skip=true -DfailIfNoTests=false \
-Dmaven.build.cache.enabled=false \
-Dtest=FloatLiteralTest,DoubleLiteralTest,DecimalLiteralTest,CompareLiteralTest,FoldConstantTest,ConstantProjectionFoldingTest,NumericArithmeticTest,CastTest
```
About the two remaining `FoldConstantTest` failures
(`testDateConstructFunction:1552`,
`testFoldString:581`): they are **pre-existing on this machine and
unrelated to this change**.
I ran `FoldConstantTest` alone on a pristine `master` worktree with every
edit of mine stashed
and got the identical two failures:
```
[ERROR] FoldConstantTest.testDateConstructFunction:1552 expected:
<'1977-06-03 17:57:24'> but was: <'1977-06-03 15:27:24'>
[ERROR] FoldConstantTest.testFoldString:581 expected: <'2025-10-27
14:58:08.100000'> but was: <'2025-10-27 12:28:08.100000'>
[ERROR] Tests run: 27, Failures: 2, Errors: 0, Skipped: 0
```
They are timestamp assertions that depend on the session time zone of the
environment, and
neither touches float/double/decimal folding.
Environment: JDK 17.0.20 (Temurin), Maven 3.9.16, thrift compiler 0.24.0
from the prebuilt
thirdparty package, Ubuntu 22.04 under WSL2. Style gate
`mvn -pl fe-core checkstyle:check` -> `You have 0 Checkstyle violations.`
- Behavior changed:
- [ ] No.
- [x] Yes. <!-- Explain the behavior change -->
Folding `CAST(<float literal> AS DOUBLE)` and `CAST(<float literal> AS
DECIMAL(p,s))` now
produces the same value the BE produces for a `FLOAT` column, i.e.
`CAST(CAST(0.1 AS FLOAT)
AS DOUBLE)` is `0.10000000149011612` instead of `0.1`. The old folded
value was the one that
was wrong. No other cast target changes.
- Does this need documentation?
- [x] No.
- [ ] Yes. <!-- Add document PR link here. -->
### Check List (For Reviewer who merge this PR)
- [ ] Confirm the release note
- [ ] Confirm test cases
- [ ] Confirm document
- [ ] Add branch pick label
### AI assistance disclosure
An AI coding agent was used to draft this change and the updated assertions.
I read and reviewed
every line myself, ran the FE unit tests above on the exact commit in this
branch, including the
pristine-master control run quoted above, and I take responsibility for the
result. The production
change is two expressions in one file.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
