`legacy_directory_ownership` future-compatibility warnings

[jseyfried]

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_ownership lint as warn-by-default
• Make sufficiently old or low-impact compatibility lints deny-by-default #42894 makes the legacy_directory_ownership lint deny-by-default
• PR ? makes the legacy_directory_ownership lint a hard error

[cramertj]

@jseyfried Do you know of any blockers to making this a hard error? In #46936 (comment) it was discovered that the ring crate 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 shows atomic-0.3.3 as the only failure due to this feature.

[SimonSapin]

Aren’t new epochs when we make breaking changes such as turning warnings into errors?

[cramertj]

@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]

@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.