Parse scientific notation in calc() expressions#2562
Draft
posthog[bot] wants to merge 1 commit into
Draft
Conversation
The calc-expression tokenizer only consumed digits and decimal points when scanning a number. A near-zero PCB coordinate that stringifies in scientific notation (e.g. "1.1368683772161603e-13mm") caused the scanner to stop at the "e", then treat "e" as a unit and throw "Unknown unit: e" — surfacing to users as "Invalid pcbY value for SmtPad: Invalid calc() expression". Teach the number scanner to consume an optional exponent ([eE][+-]?digits) before reading a unit, so scientific-notation values parse as plain numbers. Generated-By: PostHog Code Task-Id: 1ba46a7c-5db7-4040-ae55-c65c320bda42
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
This PR has been automatically marked as stale because it has had no recent activity. It will be closed if no further activity occurs. |
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
Fixes a real runtime error where valid near-zero PCB coordinates broke
SmtPadplacement.The
calc()tokenizer inlib/utils/evaluateCalcString.tsonly consumed digits and decimal points when scanning a number. When a coordinate came out as floating-point noise near zero and got stringified in scientific notation (e.g.1.1368683772161603e-13mm), the scanner stopped at thee, then treated the leftovereas a unit — throwingUnknown unit: "e". That bubbled up through_validatePcbCoordinateReferencesand surfaced to users asInvalid pcbY value for SmtPad: Invalid calc() expression.The fix teaches the number scanner to consume an optional exponent (
[eE][+-]?digits) before reading a unit, so scientific-notation values parse as plain numbers. The exponent is only consumed when actually followed by (optional sign +) digits, so identifiers and strayes are unaffected.Why
Error tracking showed this firing repeatedly across multiple users and sessions over a couple of days — a genuine defect on valid input, not user mistake. It breaks coordinate resolution on affected pads whenever a legitimate near-zero value happens to render in scientific notation.
Test plan
tests/utils/evaluate-calc-string-scientific-notation.test.tscovering the reported value, positive/negative/signed exponents, scientific notation insidecalc()with arithmetic, and that plain numbers/units still parse.calc-pcb-position*suites still pass; typecheck clean.Created with PostHog Code from an inbox report.