Closed abonander closed 5 years ago
I confirm that problem, however the bug is not in this crate nor in rusticata-macros
.
This is caused by nom
defining a dbg
macro and rust deciding to use it even without a use
statement.
As a workaround, it's possible to use ::std::dbg!()
instead of dbg!()
until it is fixed.
I forwarded your issue to nom (https://github.com/Geal/nom/issues/1022) with an example, so closing this one.
@chifflier the issue is that #[macro_use] extern crate nom;
is neccessary in user code in the first place. You have to reexport macros you intend to use from other crates in your own macros.
Or, you have to show in your examples that this is needed. It appears there are no files in tests/
that use the macros so that's why you wouldn't have seen this.
Oh, maybe I didn't get the issue right then (reopening). I'll check if re-exporting macros works.
That said, there is code in tests using macros, see https://github.com/rusticata/der-parser/blob/master/tests/constructed.rs (but it imports everything).
@abonander 3f896e2f should fix the problem by allowing to use der-parser
macros without importing nom
nor rusticata-macros
. I'm running more tests, but if it works correctly, it could justify a new release.
Note I had to add new result types to hide nom::IResult
Result types (and removal of now unneeded imports) have been generalized in d24fdcc and 0b6e713
der-parser
macros can now be used without importing other crates.
Thanks for the suggestion of re-exporting macros, it helped solving the problem.
Forgot to say: der-parser
3.0.1 has been published
Thanks!
Using any of the macros in this crate requires both of the following imports in one's own code to work:
The former breaks code if you use
dbg!()
from the standard library because Nom defines the same macro name with incompatible semantics.