Nonsensical `#[path]` attributes are allowed.

[theemathas]

The following code compiles without errors:

#[path = "foo.rs"]
mod sub {}

The following code also compiles without errors, when the code is put into a submodule file:

#![path = "foo.rs"]

In both cases, the attribute seems to do nothing. They probably shouldn't compile.

cc @JonathanBrouwer @jdonszelmann

Meta

rustc version 1.96.0

[JonathanBrouwer]

From reading the rust reference: https://doc.rust-lang.org/reference/items/modules.html?highlight=path%20attribute#r-items.mod.outlined.path.search-nested

This seems to intended and to actually have a meaning! I also did not know this

#[path = "thread_files"]
mod thread {
    #[path = "tls.rs"]
    mod local_data;
}

This tries to load the local_data module from thread_files/tls.rs

[theemathas]

That explains the first weirdness 😅

What about the second one?

[JonathanBrouwer]

Hmmm from local testing that doesn't seem to have an effect, so we should probably emit a warning on that indeed.
I'm keeping this open for a bit as a good first issue in case anyone wants to do it :)

[winterqt]

@rustbot claim

I think the context provided in SingleAttributeParser::convert might be enough here, but not 100% sure whether this is true yet. Will keep digging.

Edit: yeah, looks like it, cool.

[JonathanBrouwer]

@winterqt I'm not actually sure it is, because we specifically want to provide a warning when the module that #[path] is on is from a file, and we don't have any specific information about the target in the attribute parsers by design.

That is, make sure following will not be warned on: (regardless of how weird it is haha)

mod thread {
    #![path = "thread_files"]
    #[path = "tls.rs"]
    mod local_data;
}

Please add a test for this and the other examples as well, if they don't already exist

If you can't find a way to make it work in the context, I'd recommend adding a check in check_attr.rs