Repository navigation
E0365 newly triggers on pub(crate) reexports (cannot be re-exported outside) #156264
Description
I have had trouble creating a minimal repro for this, however I do think this is potentially unwanted breakage. On the latest nightly, I tried compiling the latest version of the serenity crate (v0.12.5) and received a compiler error:
error[E0365]: `Result` is only public within the crate, and cannot be re-exported outside
--> src/lib.rs:185:9
|
185 | model::prelude::*,
| ^^^^^^^^^^^^^^^^^ re-export of crate public `Result`
|
= note: consider declaring type or module `Result` with `pub`
error[E0365]: `Error` is only public within the crate, and cannot be re-exported outside
--> src/lib.rs:185:9
|
185 | model::prelude::*,
| ^^^^^^^^^^^^^^^^^ re-export of crate public `Error`
|
= note: consider declaring type or module `Error` with `pub`
Code
I tried creating a minimal repro, but no luck. However, the relevant module structure in serenity is described below:
mod error {
pub enum Error {
// ...
}
pub type Result<T, E = Error> = std::result::Result<T, E>;
}
mod internal {
pub mod prelude {
pub use crate::error::{Error, Result};
// ...
}
}
pub mod model {
pub mod prelude {
pub(crate) use crate::internal::prelude::*;
// ...
}
}
pub use crate::error::{Error, Result};
pub mod all {
pub use crate::model::prelude::*;
// ...
}This code by itself is not a repro, however the important thing to note is that the error::{Result, Error} types are exported publicly at the root level of the crate, and additionally exported as part of the internal prelude that is re-exported within the model::prelude, but only at the pub(crate) level. This lets other modules within the crate obtain the contents of the interal::prelude module by importing module::prelude::*.
Something to do with this code causes serenity to no longer compile on nightly-2026-05-06. I was able to bisect down to #156014, specifically this code which is responsible for the error being emitted.
Version it worked on
It most recently worked on nightly-2026-05-05:
rustc 1.97.0-nightly (cb40c25f6 2026-05-04)
binary: rustc
commit-hash: cb40c25f6aebb637163d26bf76a680ed6e5d1eda
commit-date: 2026-05-04
host: x86_64-unknown-linux-gnu
release: 1.97.0-nightly
LLVM version: 22.1.4
Version with regression
The most recent nightly fails to build the crate:
rustc 1.97.0-nightly (e95e73209 2026-05-05)
binary: rustc
commit-hash: e95e73209faf6ead2bc5c7636e45e589a751b79b
commit-date: 2026-05-05
host: x86_64-unknown-linux-gnu
release: 1.97.0-nightly
LLVM version: 22.1.4
@rustbot modify labels: +regression-from-stable-to-nightly -regression-untriaged
Activity
petrochenkov commentedon May 7, 2026
If macros 2.0 (the
macrokeyword) are not involved, then something is indeed going wrong and these errors should not appear.I'll look into this in a few days, but it would still be very useful to have some minimized reproduction until then.
cyrgani commentedon May 7, 2026
the above example is actually almost correct; the following compiles on stable but not on nightly
or smaller:
petrochenkov commentedon May 7, 2026
Fixed in #156284.
CI: pin nightly to 2026-05-04 to dodge serenity E0365 regression
Restore nightly clippy/fmt with date pin and box SerenityError
CI: keep cargo-make installed and stash original invocations
Restore nightly clippy/fmt with date pin and box SerenityError
CI: keep cargo-make installed and stash original invocations
Add a regression test for issue rust-lang#156264
Rollup merge of rust-lang#156284 - petrochenkov:kvak2, r=mu001999
Unrolled build for #156284