Follow `path` attribute on inline `mod` blocks about cargo-mutants HOT 5 CLOSED

Thanks for the followup mention.

I plan on taking a look at implementing this, but likely wouldn't be until next weekend.

from cargo-mutants.

@danjl1100 no obligation, but if you want to take this one let me know.

from cargo-mutants.

My initial thoughts, any guiding feedback is welcome:

• Thinking to use the same testdata/nested_mod test case, and add all the examples listed in the rust reference you linked. Possibly add more levels of nesting too, so it's fairly exhaustive.
• Introduce a new struct (ModNamespace?) to contain the name and optional path for each module in the mod_namespace_stack: Vec<ModNamespace>

from cargo-mutants.

On further look, only the path to the module (not the module name identifiers) are used in find_mod_source. I am thinking an extra struct is not needed: the separation from namespace_stack (all rust identifiers) means that mod_namespace_stack can contain just the filesystem names for the modules (without carrying around name as well).

Though it may be helpful to add a struct FilesystemName(String) newtype wrapper to ensure we're acknowledging it's a path and not an identifier? (otherwise, may be unclear on a quick skim that the different Vec<String> fields are tracking subtly different values...)

UPDATE: mod_name is output by the warn!, do we want to keep the module name around for that purpose alone?

from cargo-mutants.

Using the same test case but with some addition modules containing #[path] attributes sounds good.

Even though it's not really a security boundary we should check that paths don't contain .. or /.

Though it may be helpful to add a struct FilesystemName(String) newtype wrapper to ensure we're acknowledging it's a path and not an identifier?

Yes, the Vec<Vec<String>> feels a bit loose. Though, on the other hand, maybe it should just be a Utf8PathBuf which is basically like a FilesystemName(String): a stack holding the relative directory we'll search, and then the visitor can accumulate the paths of actual modules we need to later find. Then we need to translate a/b/c to either a/b/c.rs or a/b/c/mod.rs unless we had a specific path for c, but there's already some code like that.

Regarding the "not found" message:

1. Maybe that should be upgraded to an error rather than warning, and cause a non-zero exit.
2. Maybe the more useful thing there would be to remember and report not just the mod name but the source file/line/col of the mod statement.

Also, I think this bug is some additional evidence for the refactor considered in #329 of separating walking mods from generating mutants, but that might be large so I'd rather do it myself. It shouldn't block or conflict with this.

from cargo-mutants.