Repository navigation
legacy_directory_ownership future-compatibility warnings #37872
Description
This is the summary issue for the legacy_directory_ownership future-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_ownership warning is issued when
- there is a non-inline module with a
#[path]attribute (e.g.#[path = "foo.rs"] mod bar;), - the module's file ("foo.rs" in the above example) is not named "mod.rs", and
- the module's file contains a non-inline child module without a
#[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
- parser: simplify directory ownership semantics #37602 introduces the
legacy_directory_ownershiplint as warn-by-default - Make sufficiently old or low-impact compatibility lints deny-by-default #42894 makes the
legacy_directory_ownershiplint deny-by-default - PR ? makes the
legacy_directory_ownershiplint a hard error
Activity
[-]`DIRECTORY_OWNERSHIP` future-compatibility warnings[/-][+]`legacy_directory_ownership` future-compatibility warnings[/+]Merge pull request #18 from marshallpierce/split-unit-tests
cramertj commentedon Dec 22, 2017
@jseyfried Do you know of any blockers to making this a hard error? In #46936 (comment) it was discovered that the
ringcrate still depends on the old behavior, so someone needs to send a patch (I can look into it). Are there any other crates that are known to use this behavior? The list from the crater run in #42894 (comment) seems like it missed some, as it showsatomic-0.3.3as the only failure due to this feature.SimonSapin commentedon Dec 22, 2017
Aren’t new epochs when we make breaking changes such as turning warnings into errors?
cramertj commentedon Dec 22, 2017
@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.
jseyfried commentedon Dec 28, 2017
@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.
cramertj commentedon Dec 28, 2017
@jseyfried should we do a crater run on #46531, then? It would have broken affected crates because it changed the interpretation of
mod foo;in non-mod.rs files.jseyfried commentedon Dec 28, 2017
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.
Auto merge of #63247 - Centril:compat-to-error, r=<try>
Rollup merge of rust-lang#65785 - Centril:compat-to-error-2, r=oli-obk
Rollup merge of rust-lang#65785 - Centril:compat-to-error-2, r=oli-obk