Expose the nom parsers in a public parsing:: submodule
#82
Conversation
| macro_rules! tuple { | ||
| ($i:expr, $($rest:tt)*) => { | ||
| tuple_parser!($i, (), $($rest)*) | ||
| }; | ||
| } | ||
|
|
||
| /// Internal parser, do not use directly | ||
| #[macro_export] | ||
| macro_rules! tuple_parser { |
There was a problem hiding this comment.
This one should be #[doc(hidden)]
| @@ -41,36 +44,39 @@ macro_rules! map { | |||
| } | |||
|
|
|||
| /// Internal parser, do not use directly | |||
| #[macro_export] | |||
| macro_rules! map_impl { | |||
There was a problem hiding this comment.
This one should be #[doc(hidden)]
| name = "syn_nom" | ||
| version = "0.1.0" | ||
| authors = ["David Tolnay <[email protected]>"] | ||
| licence = "MIT/Apache-2.0" |
There was a problem hiding this comment.
Cargo wants this to be "license"
|
|
||
| pub use lit::parsing::int as int_lit; | ||
|
|
||
| pub use lit::parsing::boolean as bool_lit; |
There was a problem hiding this comment.
I would prefer to have these lit parsers return their own individual types - it seems silly to parse a bool_lit and then have to pattern-match on a Lit to read the bool out of it. There should be a parser called "boolean" that gives you a bool.
For string / byte string / int / float we will need some sort of wrapper struct like struct StrLit(String, StrStyle).
| pub use macro_input::parsing::macro_input; | ||
|
|
||
| #[cfg(feature = "full")] | ||
| pub use krate::parsing::krate; |
There was a problem hiding this comment.
I don't think this is one that people will need in their procedural macros, let's leave it out.
| //! thus improves build speeds. This should be used instead of `nom` when | ||
| //! building parsers using these parsers. | ||
| pub use macro_input::parsing::macro_input; |
There was a problem hiding this comment.
Let's leave this out, this one is specific to the macros 1.1 custom derive use case and isn't something people will need for other procedural macros.
| @@ -10,26 +10,29 @@ pub enum IResult<I, O> { | |||
| Error, | |||
| } | |||
|
|
|||
There was a problem hiding this comment.
Please also move all the macros in src/helper.rs - you won't get very far without those, especially punct! and keyword!. Keep them in a separate file though to track that they are not from upstream nom.
mystor
force-pushed
the
public_nom_parsers
branch
3 times, most recently
from
947b6b5 to
b9b3a81
Compare
mystor
force-pushed
the
public_nom_parsers
branch
from
b9b3a81 to
5e107ff
Compare
|
@utkarshkukreti what do you need it for? I was not in a hurry to release because I didn't think this would be useful until function-like procedural macros land in nightly. |
|
@dtolnay I'm writing a template engine and need to be able to parse the longest prefix of a str which is a valid expression. I was using a pretty inefficient way to solve this earlier -- trying to parse an expression at every whitespace and taking the last valid one (which was very slow) before I found this pull request. Thanks for the release! One quick question: is there any reason you haven't exposed the |
|
I agree, perhaps we started with too conservative of a choice of functions. I added |
|
Thanks, I definitely needed |
I quickly threw this together, because this solution is super easy and straightforward.
Fixes #81.