Implement hexadecimal floating point literals via a syntax extension #12652
Conversation
|
While I thank you for this PR, I question whether this feature deserves its own crate in the main rust distribution. |
|
I was basing the design of the fourcc! macro. Is there a better way to arrange syntax extensions? |
|
@brson Imo we should support at least some kind of hex float literals in the main distribution (syntaxext or literal). Having only base 10 literals means specifying an bit-exact float value becomes almost impossible. |
| let mut chars = s.chars().peekable(); | ||
| let mut i = 0; | ||
| if *chars.peek().unwrap_or(&'_') == '-' { chars.next(); i+= 1 } | ||
| if chars.next().unwrap_or('_') != '0' { return Some((i, ~"Expected '0'")); } i+=1; |
There was a problem hiding this comment.
Why not if chars.next() != Some('0')?
There was a problem hiding this comment.
That would be neater. Thanks! I'm still learning to think in terms of rust.
|
@rcxdude Understood re the fourcc crate (I'm not sure how I feel about that crate either). We don't have a lot of precedent for adding syntax extensions outside of rustc. I'd like to hear @alexcrichton and @pcwalton's opinions about how we should be evaluating and organizing these. |
|
It seems that it would be fairly easy to group syntax extensions into their own crate. However it would work a lot better if macros were more similar to other objects in terms of their interaction with crates, e.g. I'm interested in working on this, as well as other macro features. |
|
@rcxdude sadly, it's not that easy... My plans involve intertwining expansion with resolve, for performance and features like that (and more hygiene etc.). |
|
I'm as ok with including this as I am with Syntax extensions and their tests are always pain points in snapshots, cross compilation, and in general due to how flaky they are. |
|
Can you squash these commits? Other than that, I think this is ready to go. |
|
done. |
|
Sorry about the test failure. Looks like |
Closes #1433. Implemented after suggestion by @cmr in #12323 This is slightly less flexible than the implementation in #12323 (binary and octal floats aren't supported, nor are underscores in the literal), but is cleaner in that it doesn't modify the core grammar, or require odd syntax for the number itself. The missing features could be added back with relatively little effort (the main awkwardness is parsing the string. Is there a good approach for this in the stdlib currently?)
Closes #1433. Implemented after suggestion by @cmr in #12323 This is slightly less flexible than the implementation in #12323 (binary and octal floats aren't supported, nor are underscores in the literal), but is cleaner in that it doesn't modify the core grammar, or require odd syntax for the number itself. The missing features could be added back with relatively little effort (the main awkwardness is parsing the string. Is there a good approach for this in the stdlib currently?)
internal: Try to publish releases to OpenVSX
Fix markdown syntax in str_split_at_newline docs changelog: [`str_split_at_newline`] Fix formatting of docs
Closes #1433. Implemented after suggestion by @cmr in #12323
This is slightly less flexible than the implementation in #12323 (binary and octal floats aren't supported, nor are underscores in the literal), but is cleaner in that it doesn't modify the core grammar, or require odd syntax for the number itself. The missing features could be added back with relatively little effort (the main awkwardness is parsing the string. Is there a good approach for this in the stdlib currently?)