Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrectly reported orphan module #302

Closed
nigeleke opened this issue Jun 21, 2024 · 1 comment
Closed

Incorrectly reported orphan module #302

nigeleke opened this issue Jun 21, 2024 · 1 comment

Comments

@nigeleke
Copy link

I have a module that is only used in a test configuration:

#[cfg(test)]
mod my_test_only_module;

fn main() {
    println!("Hello, world!");
}

cargo modules orphans reports this as an orphan, whereas cargo modules orphans --cfg-test does not (correctly so).

I would expect mod my_test_only_module to only be reported as a orphan in the case where:
a) it wasn't conditionally used and
b) where it has not been otherwise used.

Is there an additional argument I should apply when I perform the cargo modules orphans example and look for orphans in my non-test code?

@regexident
Copy link
Owner

Hi @nigeleke,

cargo-modules can only see what's included in the module tree (as loaded by rust-analyzer) for a particular check, i.e. either unconditional items or those with #[cfg(…)] macro attributes matched by the current config.

Rust's #[cfg(…)] macro attributes however are Turing complete (due to proc-macros) and thus undecidable, so any attempt to be "more smart" about them is futile, unfortunately.

For the case of #[cfg(test)] I suppose one could make cargo-modules have rust-analyzer load the project twice (and at the cost of double the loading time), once with and once without --cfg-test included and then only report orphans that were detected with both configs. But that still wouldn't address false positives reported due to say the use of #[cfg(target = …)].

One cannot simply filter out any orphans with a #[cfg(test)] attribute either, as those aren't loaded by rust-analyzer in the first place. And even if they were, what about #[cfg_attr(condition, test)], which in the general case is undecidable?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants