Allow use of crate without extra use statements

[focusaurus]

With these changes, I can use der_parser macros without seemingly-extraneous use statements.

I used to need the following in order to use der_parser even though my code did not directly use these names:

use der_parser::{der_read_element_header, DerObject, DerObjectContent};

With these changes, I don't need that use statement anymore.

I asked about this in this stackoverflow question and this PR is based on the answer I got.

[focusaurus]

CI failure looks like a rustup configuration problem:

error: no default toolchain configured

[chifflier]

Thanks for the PR.

I triggered a rebuild, that seems to fix the CI failure.

Rather than specifying the crate name, it is better to use the $crate variable (see https://doc.rust-lang.org/1.7.0/book/macros.html#the-variable-crate). That way, yo don't have to add the use statements neither the caller, nor in the macro.

Can you rewrite your patch and resubmit ?

[focusaurus]

OK I made that change. It seems that syntax doesn't work for where der_read_element_header is referenced so I still needed a use $crate::der_read_element_header; statement for those.

[focusaurus]

If you are OK with this approach, there's a similar thing with the error_if macro as well.

[chifflier]

Making macros more hygienic is a good thing, so error_if should also be patched to use the ::nom namespace and not force to import it. I think it is possible to do the same for der_read_element_header, that is write $crate::der_read_element_header on every call inside the macro.

[chifflier]

Merged, thanks. I'll look at the der_read_element_header calls

[focusaurus]

Yeah if I try to use $crate::der_read_element_header I get a compile error which looks unrelated to me but is caused by this change somehow.

error: no rules expected the token `i`
   --> src/der_parser.rs:886:9
    |
886 | /         parse_der_defined_m!(i, 0x10,
887 | |             parse_der_integer >>
888 | |             call!(parse_der_integer)
889 | |         )
    | |_________^ in this macro invocation
    |
    = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)