Tracking issue for legacy_constructor_visibility
compatibility lint
#39207
Labels
A-lint
Area: Lints (warnings about flaws in source code) such as unused_mut.
B-unstable
Blocker: Implemented in the nightly compiler and unstable.
C-future-incompatibility
Category: Future-incompatibility lints
T-lang
Relevant to the language team, which will review and decide on the PR/issue.
What is this lint about
#38932 introduces new rules for privacy of tuple struct constructors. Constructor is a function automatically created by a tuple struct having the same name as the struct itself.
See RFC 1506 for more details.
With these new rules constructor function of a public
struct S(....)
is defined as private if at least one of the fields is private.More precisely,
visibility(constructor_fn) = min(visibility(struct), visibility(field_1), ..., visibility(field_N))
(this definition takes RFC 1422 into account).This change is done to make a struct with private fields being a tuple struct an implementation detail. So libraries can freely change it into non-tuple struct and back, and nothing breaks.
This change is mostly backward compatible due to some ad-hoc privacy checks existing previously (e.g.
error[E0450]: cannot invoke tuple struct constructor with private fields
), however there's one pattern that is broken by it:legacy_constructor_visibility
lint tries to detect this patterns and make name resolution succeed with a warning to keep backward compatibility. However, this detection is pretty hacky and not entirely precise, so it will need to go away eventually.How to fix this warning/error
Use the constructor from its original location X and not through reexports in modules outer to X.
Current status
legacy_constructor_visibility
lint as deny-by-defaultlegacy_constructor_visibility
lint a hard errorThe text was updated successfully, but these errors were encountered: