Security vulnerability exploiting compiler's ignorance

[iyernaveenr]

effectively ignoring 2 of 3).

Well, if you replace the statement "mod my_module" with an inline module, it should not surprise that the file is ignored?
I think the only remaining question left is, if a combination of hosting/mod.rs with hosting.rs could make any sense, when both files have different content? But note, that the use of mod.rs files is legacy, which should not be used in new projects generally. And mixing both versions in a single crate is generally strongly dis-curated. I think this was told in some books. I think there was one special case mentioned somewhere, where mod.rs modules can make still some sense in modern Rust, but I can currently not remember details.
It is nice that you tested so carefully all variants, but still I would suggest closing this issue. Or tell us exactly where in our books the description is wrong.

That special case you are referring to is under Section 11.3, subsection "Submodules in Integration Tests": https://doc.rust-lang.org/book/ch11-03-test-organization.html#submodules-in-integration-tests For the case mentioned in the book, 3 of 3) seems to be the only way to prevent common from appearing in the test results.

Inlining is fine, but then the wording in the book is ambiguous w.r.t the interpretation by a compiler. Is the compiler supposed to error out in cases when multiple forms of declaring modules were used? Or, is the compiler supposed to silently prefer one over the other? Whichever behavior is chosen, that should've been used consistently for any combination of module declarations used. But what was observed, as evidenced by the details I shared, is the inconsistent/biased behavior by the compiler.

I would personally prefer that the compiler error out. The reason for that is, imagine this - If I wanted to sneak in a malicious piece of code (say a backdoor, for example), all I have to do is to exploit this silent ignorance of the compiler to sneak in code. So, wherever a module is declared as per 1 of 3), I could simply add malicious code by replacing the semicolon with my code enclosed with curly braces. Maintainer of that code may not realize until it's too late, if at all, that their original code, which had resided in a file named after the module was never compiled into the final binary. This could be a serious security issue.

This is the reason I had originally posted this as an internal compiler issue, since I would've liked the compiler developers to handle this case as well. But then they suggested I post it here instead. I believe this is an issue that should not be closed, but instead be perused and if needed, escalated to handle the potential scenario where hackers could sneak in malicious code.

I think it's worthwhile to consider re-opening this as an internal compiler issue due to this scenario I shared above, link to the above is as follows:
rust-lang/book#4334 (comment)

Originally posted by @iyernaveenr in #139685

I did not have enough permissions/privilege to re-open the aforementioned issue. Hence, opened a new one, referencing the old one. Modified the title to better categorize this issue.

[saethlin]

If you believe you are reporting a security issue, report it via our security policy: https://www.rust-lang.org/policies/security

[iyernaveenr]

If you believe you are reporting a security issue, report it via our security policy: https://www.rust-lang.org/policies/security

Done. Looking forward to the response. Thanks!

[fmease]

Closing in favor of email