@@ -115,7 +119,9 @@ The error message is presented as a `TokenStream` throught the `.emit()` functio
...
@@ -115,7 +119,9 @@ The error message is presented as a `TokenStream` throught the `.emit()` functio
For the first case (`lit!(99)`) the parsing succeeded and the returned token stream would amount to the literate integer 99. As our `v` is a `LitInt` we need to convert it into a `TokenStream`, a two stage process by first turning `v` into tokens, from wich we get a token stream. (You may comment out the failing parts and print the value of `_v` to convince yourself.)
For the first case (`lit!(99)`) the parsing succeeded and the returned token stream would amount to the literate integer 99. As our `v` is a `LitInt` we need to convert it into a `TokenStream`, a two stage process by first turning `v` into tokens, from wich we get a token stream. (You may comment out the failing parts and print the value of `_v` to convince yourself.)
For the second and third cases, we see that appropriate errors and spans are reported by the built in parser. However the last case is somewhat unsatisfying, due to the `syn::parse` failing (unwrap on an `Err`). We can improve that as follows, `ex_lite.rs`.
For the second and third cases, we see that appropriate errors and spans are reported by the built in parser. However the last case is somewhat unsatisfying, due to the `syn::parse` failing (unwrap on an `Err`) the procedural macro fails with a panic. Hence the `lit!(0)` is never parsed and the error reporting hempered.
The description here is the default error, provided by the built in `LitInt` parser.
The description here is the default error, provided by the built in `LitInt` parser.
## Direct approach
## Combining parsers
The real strenght of the `syn` and `nom` frameworks comes from the ability to combine parsers. We will start by looking at the last error, assuming we want to parse something like `(LitInt)` into a plain `LitInt`.