-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
Enforce the file system hierarchy more strictly for modules #14180
Labels
A-parser
Area: The parsing of Rust source code to an AST
B-RFC-approved
Blocker: Approved by a merged RFC but not yet implemented.
Milestone
Comments
Nominating. |
P-backcompat-lang, 1.0. |
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
May 17, 2014
This is an implementation of RFC 16. A module can now only be loaded if the module declaring `mod name;` "owns" the current directory. A module is considered as owning its directory if it meets one of the following criteria: * It is the top-level crate file * It is a `mod.rs` file * It was loaded via `#[path]` * It was loaded via `include!` * The module was declared via an inline `mod foo { ... }` statement For example, this directory structure is now invalid // lib.rs mod foo; // foo.rs mod bar; // bar.rs; fn bar() {} With this change `foo.rs` must be renamed to `foo/mod.rs`, and `bar.rs` must be renamed to `foo/bar.rs`. This makes it clear that `bar` is a submodule of `foo`, and can only be accessed through `foo`. RFC: 0016-module-file-system-hierarchy Closes rust-lang#14180 [breaking-change]
bors
added a commit
that referenced
this issue
May 19, 2014
This is an implementation of RFC 16. A module can now only be loaded if the module declaring `mod name;` "owns" the current directory. A module is considered as owning its directory if it meets one of the following criteria: * It is the top-level crate file * It is a `mod.rs` file * It was loaded via `#[path]` * It was loaded via `include!` * The module was declared via an inline `mod foo { ... }` statement For example, this directory structure is now invalid // lib.rs mod foo; // foo.rs mod bar; // bar.rs; fn bar() {} With this change `foo.rs` must be renamed to `foo/mod.rs`, and `bar.rs` must be renamed to `foo/bar.rs`. This makes it clear that `bar` is a submodule of `foo`, and can only be accessed through `foo`. RFC: 0016-module-file-system-hierarchy Closes #14180 [breaking-change]
flip1995
pushed a commit
to flip1995/rust
that referenced
this issue
Feb 20, 2025
…n Rust editions (rust-lang#14180) The first commit fixes rust-lang#14164 by making sure that temporaries with non-static references are also looked for in expressions coming from expansion. The shortcut that was done skipped those parts and reported an absence of short-lived temporaries, which was incorrect. The second commit distinguishes between edition 2024 and earlier ones. Starting from edition 2024, the problematic drop order has been fixed, and block variables, which might be referenced in a block expression, are freed after the block expression itself. This allows more `let_and_return` cases to be reported starting with edition 2024, whereas in earlier editions an intermediary variable was necessary to reorder the drops. Incidentally, since Clippy is compiled in edition 2024 mode, the second commit has led to a fix in `clippy_lints/src/matches/significant_drop_in_scrutinee.rs`. changelog: [`let_and_return`]: lint more cases in edition 2024, and fix a false positive involving short-lived block temporary variables in earlier editions.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-parser
Area: The parsing of Rust source code to an AST
B-RFC-approved
Blocker: Approved by a merged RFC but not yet implemented.
Tracking issue for rust-lang/rfcs#63
The text was updated successfully, but these errors were encountered: