legacy_directory_ownership future-compatibility warnings
#37872
Comments
jseyfried
changed the title
DIRECTORY_OWNERSHIP future-compatibility warningslegacy_directory_ownership future-compatibility warnings
nikomatsakis
added
B-unstable
Split the unit tests into several files. Also addresses rust-lang/rust#37872.
Mark-Simulacrum
added
the
C-tracking-issue
|
@jseyfried Do you know of any blockers to making this a hard error? In #46936 (comment) it was discovered that the |
|
Aren’t new epochs when we make breaking changes such as turning warnings into errors? |
|
@SimonSapin Epochs are for releasing breaking changes to the language that were warnings in the last epoch. This is not a breaking change to specified language behavior-- it's a bugfix. As specified in RFC 1589, bugfixes are "[p]laces where the compiler is not implementing the specified semantics found in an RFC or lang-team decision." RFC 1122 has more details on what sorts of breaking changes are permitted under Rust's semver guarantees. |
|
@cramertj I'm not aware of any other blockers, but there might be other crates that were broken -- it's been a while since the Crater run. |
|
@jseyfried should we do a crater run on #46531, then? It would have broken affected crates because it changed the interpretation of |
|
Good point. I don't think breakage is likely, but a Crater run might be warranted. I think it would be better to just do (or wait for) a stable- or beta-to-nightly Crater to also see if there's any other breakage from making this a hard error. |
Treat #[path] files as mod.rs files Fixes rust-lang#46936, cc @briansmith, @SergioBenitez, @nikomatsakis. This (insta-stable) change treats files included via `#[path = "bla.rs"] mod foo;` as though they were `mod.rs` files. Namely, it allows them to include `mod` statements and looks for the child modules in sibling directories, rather than in relative `modname/childmodule.rs` files as happens for non-`mod.rs` files. This change makes the `non_modrs_mods` feature backwards compatible with the existing usage in https://github.com/briansmith/ring, several versions of which are currently broken in beta. If we decide to merge, this change should be backported to beta. cc rust-lang#37872 r? @jseyfried
Treat #[path] files as mod.rs files Fixes rust-lang#46936, cc @briansmith, @SergioBenitez, @nikomatsakis. This (insta-stable) change treats files included via `#[path = "bla.rs"] mod foo;` as though they were `mod.rs` files. Namely, it allows them to include `mod` statements and looks for the child modules in sibling directories, rather than in relative `modname/childmodule.rs` files as happens for non-`mod.rs` files. This change makes the `non_modrs_mods` feature backwards compatible with the existing usage in https://github.com/briansmith/ring, several versions of which are currently broken in beta. If we decide to merge, this change should be backported to beta. cc rust-lang#37872 r? @jseyfried
Treat #[path] files as mod.rs files Fixes rust-lang#46936, cc @briansmith, @SergioBenitez, @nikomatsakis. This (insta-stable) change treats files included via `#[path = "bla.rs"] mod foo;` as though they were `mod.rs` files. Namely, it allows them to include `mod` statements and looks for the child modules in sibling directories, rather than in relative `modname/childmodule.rs` files as happens for non-`mod.rs` files. This change makes the `non_modrs_mods` feature backwards compatible with the existing usage in https://github.com/briansmith/ring, several versions of which are currently broken in beta. If we decide to merge, this change should be backported to beta. cc rust-lang#37872 r? @jseyfried
Mark-Simulacrum
added
C-future-incompatibility
Transition some C-future-compatibility lints to {ERROR, DENY}
Closes #40107 (ERROR).
Closes #39207 (ERROR).
Closes #37872 (ERROR).
Closes #36887 (ERROR).
Closes #36247 (ERROR.
Closes #42238 (ERROR).
Transitions #59014 (DENY).
Transitions #57571 (DENY).
Closes #60210 (ERROR).
Transitions #35203 (DENY).
r? @petrochenkov
Transition future compat lints to {ERROR, DENY} - Take 2
Follow up to rust-lang#63247 implementing rust-lang#63247 (comment).
- `legacy_ctor_visibility` (ERROR) -- closes rust-lang#39207
- `legacy_directory_ownership` (ERROR) -- closes rust-lang#37872
- `safe_extern_static` (ERROR) -- closes rust-lang#36247
- `parenthesized_params_in_types_and_modules` (ERROR) -- closes rust-lang#42238
- `duplicate_macro_exports` (ERROR)
- `nested_impl_trait` (ERROR) -- closes rust-lang#59014
- `ill_formed_attribute_input` (DENY) -- transitions rust-lang#57571
- `patterns_in_fns_without_body` (DENY) -- transitions rust-lang#35203
r? @varkor
cc @petrochenkov
This is the summary issue for the
legacy_directory_ownershipfuture-compatibility warning and other related errors. The goal of this page is describe why this change was made and how you can fix code that is affected by it. It also provides a place to ask questions or register a complaint if you feel the change should not be made.What is the warning for?
The
legacy_directory_ownershipwarning is issued when#[path]attribute (e.g.#[path = "foo.rs"] mod bar;),#[path]attribute.The warning can be fixed by renaming the parent module to "mod.rs" and moving it into its own directory if appropriate.
We are making this a warning so that the directory ownership rules apply more consistently to modules with
#[path]attributes. This is described in more detail in #37602.When will this warning become a hard error?
At the beginning of each 6-week release cycle, the Rust compiler team will review the set of outstanding future compatibility warnings and nominate some of them for Final Comment Period. Toward the end of the cycle, we will review any comments and make a final determination whether to convert the warning into a hard error or remove it entirely.
Current status
legacy_directory_ownershiplint as warn-by-defaultlegacy_directory_ownershiplint deny-by-defaultlegacy_directory_ownershiplint a hard errorThe text was updated successfully, but these errors were encountered: