Add a new lint UNCONSTRUCTABLE_PUB_STRUCT to detect unconstructable public structs by mu001999 · Pull Request #146440 · rust-lang/rust (original) (raw)

We talked about this in today's @rust-lang/lang meeting.

We saw this as an extension of the existing dead_code lints; whether or not it has an additional named toggle of its own (which it probably should), once ready it should be part of the dead_code lint group, and should integrate with the dead code logic (including transitively marking things dead). Since you mention liveness propagation, you may already be doing that; we just want to make sure this gets treated as part of the dead_code lint group.

(@mu001999, this also addresses your issue with the testsuite: the testsuite implicitly has allow(dead_code), so it would allow this as well.)

The way we looked at it in the meeting, if these types were pub(crate), they would already be marked as dead. We have an exception for things that are pub, because they're public API and the user could be outside the crate. What this proposal is adding is that that exception for pub shouldn't apply to structs that nobody outside the crate can construct, at which point the same dead-code-checking logic should apply as for pub(crate).

We'd like to see a clear description of the rules for when a type is "unconstructable".

@tmandry also had a sample to consider, involving intentionally unconstructable marker types that are used in the type system only:

pub struct Mut(!); pub struct NonMut(!);

pub trait Mutness { type Ref<'a, T> where Self: 'a; }

impl Mutness for Mut { ... } impl Mutness for NonMut { ... }

This kind of type might be used in a generic, and never actually used at runtime, only used in the type system as a marker. We're not sure how prevalent this pattern is (and how often the types are unconstructable), but we want to make sure we don't have an excess of false positives caused by marker types that aren't meant to be constructable.

(The exact details of that example aren't the key point; we're mentioning it as a potential source of false positives. We'd like to hear more about the proposed rules before you delve back into further implementation work.)

Finally, we'd like to review a couple of examples (which could be links to tests you're adding in this PR, if you can highlight some representative ones for us).