Extend cfg_if! support to cfg_match!

[CAD97]

Like is done for cfg_if!, try to discover mod items that are defined in inactive cfg_match! arms.

• stdlib tracking issue: Tracking issue for cfg_select (formerly cfg_match) rust#115585

[ytmimi]

Is there a purpose to this file? lib2.rs isn't being referenced at all from lib.rs.

[CAD97]

This is a copy of the original issue-4656 regression test, where a separate file in the same session could lead to the cfg_if!-transparent mod discovery not happening in other files. Since cfg_match! duplicates much of the same handling, it could easily suffer the same regression, so it makes sense to test. The two files are loaded into the same session by the format_files_find_new_files_via_cfg_match test.

If there's a way to make this clearer, I'll happily make the change, but as-is, this is directly copied from the existing issue-4656 test, and the tested path is distinct between cfg_if! and cfg_match!.

[ytmimi]

Thanks for looking into that. In that case we can keep the test.

[CAD97]

I want to draw attention to this: cfg_match! is checking that the last path segment is cfg_match! (i.e. tries to process any::path::cfg_match!), whereas cfg_if! is checking that the first path segment is cfg_if! (i.e. tries to process cfg_if::any::path!). I think my behavior is more correct, and the worst case scenario is that some more files get discovered when a custom cfg_match! that looks similar enough to core::cfg_match! is used, but it bears pointing out.

If factoring this behavior out to be the same between the two is desirable, I can do that, and would choose to check the macro-ident, not the path front. (The current cfg_if! processing will skip ::cfg_if::cfg_if!, since the path starts with kw::PathRoot.)

[CAD97]

I went ahead and wrote the patch to unify the predicate: a129548

The visitor could be further refactored into a single KnownMacroVisitor which processes both cfg_if! and cfg_match!, but that starts to feel a bit excessive...

I haven't included it in this PR since it's behavior changing for the existing cfg_if! support, to keep this PR scoped to just the cfg_match! support.

[CAD97]

... and I ended up doing that cleanup as well: 4ae9dff

But I'm actually done doing extended cleanup for this now 😅

To be fully explicit about it: the two linked commits in this and the prior comment are made available under the same license terms as if I had directly contributed them by placing them in a PR. Feel free to pull them (or ask me to PR them) if you believe them to be an improvement.

[CAD97]

I cleaned up the added tests to only test as much as is necessary and not duplicate the stddetect snapshot. Should hopefully be reasonable to merge in this state.

[ytmimi]

Should we extend this test case to add a few different way of specifying the attribute item? Looking at the tracking issue, it looks like there are a few different ways it can be specified e.g. (unix, target_pointer_width = "32", cfg(key = "value"), and _).

cfg_match! {
    unix => {
        mod format_me_please_1
    }
    target_pointer_width = "32" => {
        mod format_me_please_2
    }
    cfg(key = "value") => {
        mod format_me_please_3
    }
    _ => {
        mod format_me_please_4
    }
}

[ytmimi]

I went ahead an added this to the test case.

[ytmimi]

Should be good to go here. Thanks for getting the ball rolling on cfg_match!.