Module declared inside macro is not checked

[mcheshkov]

When I declare modules like this

#[cfg(unix)]
pub mod stub_hal;

rustfmt will check module, irrespective of condition.

However, when I declare them using cfg-if crate rustfmt doesn't check module.

cfg_if! {
    if #[cfg(unix)] {
        pub mod stub_hal;
    }
}

Is is designed behavior? Or is macro parsing not implemented for now?

That's rustfmt 1.0.1-nightly (be13559 2018-12-10)

[topecongiro]

Parsing macro is possible only when the macro has valid syntax (e.g. println!). Most macros, including cfg_if!, contains invalid syntax in it (e.g. if #[cfg(unix)]), so rustfmt just ignores it.

[gnzlbg]

FYI this means that we can't use rustfmt effectively in rust-lang-nursery/{stdsimd, packed_simd} nor in rust-lang/libc. This appears to be hard to solve.

[topecongiro]

This seems to be not fixed in 1.3.0 😞

[calebcartwright]

@topecongiro - I believe I've got a fix for the cfg_if support (at least it's working my local env 😄)

Will open a PR shortly for review

[SOF3]

This issue also exists with dirmod users. Modules are entirely generated by the macro, so it is impossible for rustfmt to detect them with heuristics like cfg_if! did.

A useful alternative would be to allow a flag like -r that formats all files in a directory recursively, no matter explicitly included or not, similar to the suggestion in #2426.

[dylni]

Parsing macro is possible only when the macro has valid syntax (e.g. println!).

@topecongiro Does this work for modules? This module in os_str_bytes isn't formatted, but the macro uses valid syntax:

https://github.com/dylni/os_str_bytes/blob/96b3151bec06d0309f2676e835fb1ed065cb9a53/src/lib.rs#L165-L167

[SimonSapin]

I’ve run into this bug.

Parsing macro is possible only when the macro has valid syntax (e.g. println!). Most macros, including cfg_if!, contains invalid syntax in it (e.g. if #[cfg(unix)]), so rustfmt just ignores it.

That explains why rustfmt cannot easily format the tokens in a macro invocation. However, couldn’t it expand macros when looking for mod items in order to find which other files to format?

[SOF3]

That'd be too costly for a formatter that's supposed to only process the lexical level of the crate. In particular, procedural macros require compilation. If the procedural macro fails to compile, that would result in an error, which breaks backward compatibility of rustfmt.

[SimonSapin]

Right, drawing the line at proc macros makes sense to me. Would same-crate macro_rules also be too costly?

[daniel5151]

Just ran into this bug myself. gdbstub uses a declarative macro to define modules for different protocol packets, and I recently noticed that the CI wasn't enforcing formatting in them.

Is there any suggested workaround / fix on the horizon? It seems I might need to update the CI to manually invoke rustfmt on each file manually...

[Purpzie]

Currently running into this problem as well.

While it does make sense not to parse every macro like that, what if there was a #[rustfmt::follow_modules] attribute or something similar? It would go on macros where you want rustfmt to parse and find modules.

#[rustfmt::follow_modules]
macro_rules! custom_macro {
    ($(mod $mod_name:ident;)*) => {
        // do something here...
    }
}

custom_macro! {
    mod foo;
    mod bar;
    mod baz;
}

[GuillaumeGomez]

Would it be possible to mitigate this issue to add support for known/common macros like cfg_if!? I'd be willing to work on it if it can help.

[ytmimi]

@GuillaumeGomez I believe we already supported resolving modules declared in cfg_if calls, though there might be some bugs.

rustfmt/src/modules.rs

Lines 176 to 179 in 777e25a

	if is_cfg_if(&item) {
	self.visit_cfg_if(Cow::Owned(item.into_inner()))?;
	continue;
	}

[GuillaumeGomez]

Seems to not work on sysinfo as can be seen in sysinfo. But I'm glad to see it's already (at least partially) supported. Do you need help for improving its support maybe?

[ytmimi]

@GuillaumeGomez getting some help would be great. I took a stab at this back in #5341, but it hasn't been reviewed yet. If this fixes the issue I don't see why we couldn't move forward with that as a potential solution to improve the cfg_if! support.

Maybe you could build off of what's there and add a test case or two that reflects the structure of the cfg_if! code you linked to in GuillaumeGomez/sysinfo#1398.