Accept underscores in float literals (B5)#370
Open
TumCucTom wants to merge 6 commits into
Open
Conversation
Direct backend lowering diagnostics reported a generic "direct backend local type is unsupported" message regardless of the actual target, even though the expected and help fields already named the target. Substitute the generic "direct backend " prefix with a target-specific label (COFF x64, ELF64, AArch64 Mach-O, x86_64 Mach-O, COFF AArch64, AArch64 ELF) when the message originates from IR lowering. Cover the new behavior with regression tests for the linux-musl-x64, win32-x64.exe, and darwin-x64 targets in the owned-drop-direct-backend-unsupported fixture. Co-Authored-By: Zippy AI <tomkinsbale@icloud.com>
…ring-diagnostics # Conflicts: # scripts/compiler-metrics.mts
Float literals accepted `digits '.' digits` but rejected any input containing `_`, while integer literals accept `1_000.0`-style separators. The asymmetry forces numeric groupings to be omitted in float sources and produces a confusing TYP019 for `1_000.5`. Mirror the integer path: copy the source into a stack buffer, reject leading, trailing, and double underscores, then run the existing digit shape check and `strtod` on the stripped text. The behavior stays byte-equivalent for inputs without `_`. Adds a positive conformance fixture (`float-literal-underscores.0`) and a negative one (`malformed-float-underscores.0` covers trailing underscore). Bumps the `checker.c` line budget by 20.
|
@TumCucTom is attempting to deploy a commit to the Vercel Labs Team on Vercel. A member of the Team first needs to authorize it. |
Replace fixed 64-byte stack buffer with heap allocation in parse_float_literal to handle arbitrarily long (but valid) float literals without truncation (VADE fix).
Replace fixed 64-byte stack buffer with heap allocation to handle arbitrarily long valid float literals without truncation (VADE fix).
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
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
Float literals accepted
digits '.' digitsbut rejected any input containing_, while integer literals accept1_000.0-style separators. The asymmetry forces numeric groupings to be omitted in float sources and produces a confusing TYP019 for1_000.5.This PR mirrors the integer path: copy the source into a stack buffer, reject leading, trailing, and double underscores, then run the existing digit shape check and
strtodon the stripped text. Behavior stays byte-equivalent for inputs without_.Closes one item from #318 (audit finding B5, re-confirmed against
main).Test plan
conformance/native/pass/float-literal-underscores.0covers1_000.5,0.0_5,1.0e1_0,1_000.0conformance/native/fail/malformed-float-underscores.0covers trailing underscore (still TYP019)pnpm run conformancepasses (all 600+ pass fixtures, all fail fixtures)compiler-metrics.mtshas 0 violations (budget bumped by 20)