lukaskalbertodt / litrs Goto Github PK

The docs on floats https://docs.rs/litrs/latest/litrs/struct.FloatLit.html say that 27f32 is a float

A floating point literal, e.g. 3.14, 8., 135e12, 27f32 or 1.956e2f64.

Yet this fails with failed to parse as float literal: ParseError { span: None, kind: UnexpectedIntegerLit }

use litrs::{FloatLit};
let float_lit = FloatLit::parse("27f32").expect("failed to parse as float literal");

27.0f32 succeeds

I randomly stumbled upon this section of the reference talking about how all literal tokens can have suffixes, not only number literals. I wasn't aware of that at all. Rust errors if such a token ever ends up in actual Rust code, but they are valid as input to proc macros.

This library should support those.

I've started writing a conversion from (litrs::Literal, Span) to proc_macro2::Literal, and was wondering if there was a trick for doing it (given that Literal only has a ton of constructors for each sub-kind of numeric literal). If not, I was wondering if you'd take the conversion as a PR (behind a Cargo feature, of course).

If you have various primitive types in a string form from rustdocs (like 5_000i32 etc) and want to extract the 5000 without any _ (for this case a string output is fine), you can parse the strings with

pub fn value<N: FromIntegerLiteral>(&self) -> Option

But then this ignores the existing suffix

The optional type suffix of the literal is ignored by this method.

so it requires matching for all the valid suffixes to get the type N (and account for the weird fact that f32 isn't a float, but an integer, so you shouln't forget that suffix in the integers)

The alternative to get the string directly...

pub fn raw_main_part(&self) -> &str
...ignores the base

The main part containing the digits and potentially _. Do not try to parse this directly as that would ignore the base!

Would it be possible to add a function that would allow extracting the number accounting for the base and not requiring enumerating all the suffixes?

Currently Cow<'static, str> is returned, but it's always Cow::Owned. I wonder whether its more useful to have a simpler type (String instead of Cow<'static, str>) in the common case or whether always getting a Cow back is more useful. The same goes for ByteStringLit::into_value.

Your readme states:

This is particularly useful for proc macros

but yet there's no example for a proc macro.
I can understand that it would be overkill for the readme, but consider creating an examples directory and put it there for a full-fledged example.

See here: rust-lang/rust#116907

Hello, magnificent crate! 👍

I just wanted to point out that the link in the documentation of BoolLit is broken. The target https://doc.rust-lang.org/reference/tokens.html#boolean-literals does not exist anymore in the reference and should probably be replaced by https://doc.rust-lang.org/reference/keywords.html#strict-keywords and/or https://doc.rust-lang.org/reference/expressions/literal-expr.html#boolean-literal-expressions.

Most parsing code only operates on &str and does not need the generic type B: Buffer. So for compile times, it would be preferable to pull those parts into an internal non-generic function.

Default features in library crates that are not used by the vast majority of downstream crates, should likely not be default features. A quick GitHub search shows: there are 46 total repositories with litrs in Cargo.toml and 35 of those also have proc-macro2 in Cargo.toml. And 5 repositories set default-features = false for litrs. This shows what is well known: people forget to disable default features they don't need. That leads to more dependencies that are compiled for no reason. Though 35 of 46 sounds like most people use the proc-macro2 feature. Well, I have looked through a few of those repos and several do use proc-macro2 in general, but not for litrs.

So I'm inclined to make proc-macro2 a non-default feature of litrs.

Do you have any opinions, complaints, suggestions, ideas, ... about litrs? Let me know! This issue is less formal and more relaxed than "normal issues", so feel free to just dump your thoughts here.