Missing external modules don't report a build error when a crate is built from stdin.
Expected: When parsing an external submodule from stdin, a compiler error (or warning) is emitted noting that external submodules are not supported for stdio crates.
Actual: No diagnostics are emitted and an empty submodule is implicitly inserted.
Generally if a mod statement references a file which does not exist, an E0583 compile error will be emitted. However, when building a crate from stdin, no relative filesystem is present, yet no compile errors are emitted, even with explicit #[path="x"] attributes. Instead they are implicitly substituted with empty inline modules.
# Surprising stdin cases
$ echo 'mod x;' | rustc --crate-type=rlib - # Builds
$ echo '#[path="/y"] mod x;' | rustc --crate-type=rlib - # Builds
# Working file case
$ echo 'mod x;' > y.rs
$ rustc --crate-type=rlib y.rs
error[E0583]: file not found for module `x`
--> y.rs:1:5
[...]
I'm not super familiar with rustc, so this might not be handy, but I'm guessing this is caused by the Parser::recurse_into_file_modules flag being unset when parsing from a string rather than a file (rustc_interface::passes::parse -> syntax::parse::parse_crate_from_source_str -> syntax::parse::new_parser_from_source_str), leading to a dummy module being inserted rather than trying to access the filesystem or emit an error during the parse.
Missing external modules don't report a build error when a crate is built from stdin.
Expected: When parsing an external submodule from stdin, a compiler error (or warning) is emitted noting that external submodules are not supported for stdio crates.
Actual: No diagnostics are emitted and an empty submodule is implicitly inserted.
Generally if a
modstatement references a file which does not exist, an E0583 compile error will be emitted. However, when building a crate from stdin, no relative filesystem is present, yet no compile errors are emitted, even with explicit#[path="x"]attributes. Instead they are implicitly substituted with empty inline modules.I'm not super familiar with rustc, so this might not be handy, but I'm guessing this is caused by the
Parser::recurse_into_file_modulesflag being unset when parsing from a string rather than a file (rustc_interface::passes::parse->syntax::parse::parse_crate_from_source_str->syntax::parse::new_parser_from_source_str), leading to a dummy module being inserted rather than trying to access the filesystem or emit an error during the parse.