Corrected EBNF grammar for from_str

[ijchen]

Hello! This is my first time contributing to an open-source project. I'm excited to have the chance to contribute to the rust community 🥳

I noticed an issue with the documentation for from_str in f32 and f64. It states that "All strings that adhere to the following EBNF grammar when lowercased will result in an Ok being returned. I believe this is incorrect for the string ".", which is valid for the given EBNF grammar, but does not result in an Ok being returned (playground). I have simplified the grammar in a way which fixes that, but is otherwise identical.

Previously, the Number part of the EBNF grammar had an option for '.' Digit*, which would include the string ".". This is not valid, and does not return an Ok as stated. The corrected version removes this, and still allows for the '.' Digit+ case with the already existing Digit* '.' Digit+ case.

[rust-highfive]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with r? rust-lang/libs-api @rustbot label +T-libs-api -T-libs to request review from a libs-api team reviewer. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Mark-Simulacrum (or someone else) soon.

Please see the contribution instructions for more information.

[Stargateur]

This problem have been added in #94838, it's a little strange now cause EBNF is a CASE sensitive syntax. roolback the commit probably make sense @Dylan-DPC

Specially it's added "infinity" that was not mandatory before.

[ijchen]

Okay, would you like me to close this PR?

[ijchen]

For what it's worth, I do think there is some value to #94838 making it clear that from_str is case-insensitive, and that "infinity" is valid. Both of these seem intentional from parse_partial_inf_nan in dec2flt/parse.rs

I don't know what the process is for updating the docs in a way that removes something that has been mandatory, but I'd imagine that it could be potentially problematic to remove existing documentation of behavior that is currently implemented (and therefore possibly in-use). But maybe that is not really a concern

[Stargateur]

At the very least the syntax should correct the case thing cause EBNF is clear about the case, maybe use ABNF would be more clear than break EBNF rule.

[Mark-Simulacrum]

It seems like this change is correct, right? There's probably some further changes that could be made to improve things, but I don't think it's a good idea to wait until those larger changes are implemented.

@bors r+ rollup

[bors]

📌 Commit 0484cfb has been approved by Mark-Simulacrum

[Stargateur]

@ijchen Do you want to handle the following, create issue etc... (thus maybe just a PR is enough) or do you want I do it ? Basically, I think we need to switch to ABNF that is more easy and have more documentation and tool and is a lot more used than EBNF. We also need to confirm with std team what they want f64::from_str() to officially handle

[ijchen]

@Stargateur I don't mind doing it, it would be nice to get some experience with this process. Thank you though! I definitely agree that we should eventually confirm exactly what f32/f64::from_str() should officially support in documentation. The changes I made are aimed at removing only the obviously incorrect part of the documentation (considering "." a valid float).

@Mark-Simulacrum yes, as far as I can tell this change is correct (well, unless f32/f64::from_str() actually should consider "." a valid float). I definitely agree that its preferable that this is fixed sooner, even if there are still further improvements that could be made. I'm new to this process - are you guys waiting on me for something now? EDIT: Just googled what "r+ rollup" did, so I see you are not waiting on me.