Rustdoc and rustc accept different `cfg` syntax

[jyn514]

I tried this code:

#![feature(doc_cfg)]
#[doc(cfg(x, y))]
fn bar() {}

I expected to see this happen: An error, to match the behavior on #[cfg(x, y)]:

error: multiple `cfg` predicates are specified
 --> cfg2.rs:1:10
  |
1 | #[cfg(x, y)]
  |          ^

Instead, this happened: Rustdoc silently accepts the code.

Relevant code:

rust/src/librustdoc/clean/cfg.rs

Line 62 in 88b99de

crate fn parse(cfg: &MetaItem) -> Result<Cfg, InvalidCfgError> {

I think the relevant rustc code is

rust/compiler/rustc_expand/src/config.rs

Line 455 in 88b99de

fn in_cfg(&self, attrs: &[Attribute]) -> bool {

Meta

rustdoc --version: rustdoc 1.53.0-nightly (392ba2b 2021-04-17)

[jyn514]

Fixing this properly will be hard. Rustc doesn't store the cfg predicates, it evaluates them immediately and returns whether they're active in the current crate. I guess an ok solution for now is to throw lots of tests at it? I'd be worried we're missing things, though.

@petrochenkov do you have suggestions for unifying the parsing somehow? For reference, this is what rustdoc currently uses: https://doc.rust-lang.org/nightly/nightly-rustc/rustdoc/clean/cfg/enum.Cfg.html

enum Cfg {
    True,
    False,
    Cfg(Symbol, Option<Symbol>),
    Not(Box<Cfg>),
    Any(Vec<Cfg>),
    All(Vec<Cfg>),
}

It's ok for the enum to be slightly different, but it can't just be a boolean true/false because rustdoc needs to display it.

[jyn514]

Hmm, I wonder if it makes more sense to just validate the cfg once with in_cfg, ignoring the result, and then have rustdoc parse it again.