Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make scanner accept floating point literals in hex and binary #9106

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

richcarl
Copy link
Contributor

Similar to hex float literals in C 99, but using Erlang's Base#Literal notation we can easily have binary as well. For example, 2#0.10101p8, or 16#fefe.fefep-16. The letter p (as in C99) stands for powers of 2. The exponent, like the base, is always a decimal number.

These can be useful for code generators and other cases where you want to preserve an exact bit representation of a float.

Also allows explicit base 10 for completeness, as in 10#123.345e9 (with the letter e for exponent as normal - p not allowed, since it would make it very easy to miss whether it is a power of 2 or 10).

Currently missing: documentation. Might also need an EEP.

Based on #9104, which improves pinpointing of errors in numerical literals.

When the call to erl_scan succeeded returning more than one token,
for example "123_", the unexpected success was not detected.
Copy link
Contributor

github-actions bot commented Nov 24, 2024

CT Test Results

    2 files     96 suites   1h 9m 34s ⏱️
2 172 tests 2 124 ✅ 48 💤 0 ❌
2 533 runs  2 483 ✅ 50 💤 0 ❌

Results for commit 637b7fc.

♻️ This comment has been updated with latest results.

To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass.

See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally.

Artifacts

// Erlang/OTP Github Action Bot

@bjorng bjorng added team:VM Assigned to OTP team VM enhancement labels Nov 25, 2024
In cases such as "123a45", the scanner did not report an error, instead
returning two tokens '123' and 'a45'. The splitting point depends on the
base, so e.g., "16#12fg34" was scanned as '16#12f' and 'g34'. This change
makes the scanner reject numbers immediately followed by a name character.
@richcarl
Copy link
Contributor Author

Rebased on #9104 after squashing.

"1.e2",
"12._34",
"123.a4"
],
lists:foreach(
fun(S) ->
case erl_scan:string(S) of
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To improve code coverage, I suggest updating the existing helper function erl_scan_string/3 like this:

erl_scan_string(String, StartLocation, Options) ->
    case erl_scan:string(String, StartLocation, Options) of
        {ok, Tokens, EndLocation} ->
            {ok, unopaque_tokens(Tokens), EndLocation};
        {error,{_,Mod,Reason},_}=Error ->
            Mod:format_error(Reason),
            Error
    end.

Then replace all calls to erl_scan:string/1 in this PR with erl_scan_string/1.

Suggested change
case erl_scan:string(S) of
case erl_scan_string(S) of

Copy link
Contributor

@bjorng bjorng left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me. We do need an EEP for any changes to the language.

@bjorng bjorng added the testing currently being tested, tag is used by OTP internal CI label Nov 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement team:VM Assigned to OTP team VM testing currently being tested, tag is used by OTP internal CI
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants