-
Notifications
You must be signed in to change notification settings - Fork 181
Open
Description
This was somehow introduced in #752 which bumped aead to v0.6.0-rc.4, but I am baffled as to how or what's even happening.
Example reproduction
$ cd aes-gcm
$ cargo test --doc
[...]
---- aes-gcm/src/lib.rs - (line 150) stdout ----
error[E0432]: unresolved import `aes_gcm::aead::Generate`
--> aes-gcm/src/lib.rs:156:28
|
8 | aead::{Aead, AeadCore, Generate, Key, KeyInit},
| ^^^^^^^^ no `Generate` in the root
|
note: found an item that was configured outNotes
This occurs in several crates, any of which use this style of gating:
#![cfg_attr(feature = "getrandom", doc = "```")]
#![cfg_attr(not(feature = "getrandom"), doc = "```ignore")]Curiously, if the first line is changed to:
#![cfg_attr(feature = "getrandom", doc = "```ignore")]Then the test is successfully ignored, suggesting this gating somehow isn't working correctly:
running 2 tests
test aes-gcm/src/lib.rs - (line 150) ... ignored
test aes-gcm/src/lib.rs - (line 189) ... ignored
Note the other example, which depends on both the arrayvec and getrandom features, is successfully being ignored with logic like:
#![cfg_attr(all(feature = "getrandom", feature = "arrayvec"), doc = "```")]
#![cfg_attr(
not(all(feature = "getrandom", feature = "arrayvec")),
doc = "```ignore"
)]Perhaps the weirdest part is nothing in #752 actually changed how this gating worked, it just started behaving differently when the aead crate was upgraded from v0.6.0-rc.3 to v0.6.0-rc.4.
Metadata
Metadata
Assignees
Labels
No labels