Why does the rocket crate still require use of 'extern crate'? re-exporting crates

While trying to re-export rocket, I had the following problem:

rocket depends on macros to work correctly, but I know that since edition 2018 the use of

#[macro_use] extern crate rocket;

is not required anymore and in theory one can just write:

use rocket;

Somehow though, this doesn't work for the rocket crate.
I think this is the missing part to be able to re-export the rocket crate in a 'common' crate to my 'test' crate.
What am I missing? Thank you all in advance

Well, you still need the "absolute" path, in terms of modules, to the macro. For an instance, the #[get] attribute resides in rocket::get. Therefore, you would need use rocket::get.
Note: I have not actually tested out the code. But this is what theoretically should happen

1 Like

You are correct, when using

use rocket::*;

it works, though when re-exporting in a 'common' crate like this:

pub use rocket;

and importing in my crate like this:

use common::rocket::*;

it breaks again with the following error:

failed to resolve: could not find rocket in the list of imported crates
could not find rocket in the list of imported crates

Huh, that's super weird. Is it possible to share a link to the code (a repo link perhaps)?

1 Like

yes :slight_smile:

Well, with use common::rocket::*; you can’t do rocket::build(), because you aren’t importing rocket itself. build() should work though…. Or you do use common::rocket;, then rocket::build() should work instead.

1 Like

Nevertheless, the original problem still remains - the "failed to resolve: could not find rocket in the list of imported crates" still comes.

1 Like

Ah, I just realized. Rocket required Rust nightly. I think that's why it gives that error with Rust stable.

1 Like

Full error messages help. Well, now I compiled it myself to get the error message anyways. Looks to me a lot like the get macro expands to some code involving rocket::… absolute paths, so maybe you can only use it in crates that directly depend on the rocket crate themself. (I.e. you’ll need the rocket dependency in the test/Cargo.toml.)

1 Like

I picked the latest rc which is on stable :slight_smile:

So you basically say, "usually it should work like this, but in this case, because of how the rocket crate is done, it doesn't", is that correct?


That’s actually quite a bunch of proc-macros that take this approach of using absolute paths and assuming the crate name. Which can lead to problems in cases like this, or e.g. in cases where a crate has been renamed. Not quite their fault, as AFAIK, there’s no good workaround that would work as well as $crate in a macro_rules macro works.


Okay thank you. I guess I'll have to put the dependency into both crates then, which should generally be fine, I think.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.