one catch: perhaps too recent; also, this warning may be issuing with some false positives right now that would go away if we improve handling of higher-ranked subtyping (but crater runs suggested few or no such cases)
Per https://github.com/rust-lang/rfcs/pull/1589, which has not been formally accepted due to me not having found the time to update it, but I think is generally considered a reasonable policy, the idea would be this:
we put these into FCP now
we do some crater runs, gather feedback, and before next cycle make final decision
we choose between one of these actions:
keep as is
keep as lint, but defaulting to error (makes it easy to opt back out); issue stays open
this option is intended for exceptional circumstances as a way to gradually nudge people
An obvious concern is that three of these aren’t even warnings on stable yet, so converting to errors for 1.11 means they will only get 6 weeks of warnings. Perhaps these are low-enough risk. IDK.
Definitely seems time to see if we can move on PRIVATE_IN_PUBLIC.
Are any of these causing maintenance problems right now? It doesn’t hurt us to keep warning for a long time as long as the number of users of the bogus features continues shrinking.
I wanted to turn private_in_public into deny-by-default before the next release and remove ObsoleteVisiblePrivateTypesVisitor after the next release, but still leave some noticeable rule changes (as opposed to just bugs) like pub type Pub = Priv; as lints for several more cycles.
There's also match_of_unit_variant_via_paren_dotdot which is quite old (more than half a year) and deny-by-default for months. It's totally ready for removing, I was just waiting for https://github.com/rust-lang/rfcs/pull/1506 to give it a replacement (I expected it to be accepted sooner).
I believe the impact of all of these was quite small, as measured by crater (whatever that's worth). I think that UNSIZED_IN_TUPLES has a bunch of special code in the compiler; HR_LIFETIME_IN_ASSOC_TYPE somewhat less, but still some.
Really I should go do a more systematic search: I wrote this post a bit in a hurry so that I wouldn't forget about it, but I think we have a bunch of older warnings I overlooked (which don't have issues because we weren't doing that yet).
Sorry, let me clarify. I meant that the impact in terms of broken crates. (The exception to this is clearly the "private in public" rules -- I was referring to the recent warnings.)
Thanks for doing that investigation @brson! I’d personally be fine for private-in-public or transmute-from-fn-item-types to both become hard errors as they’ve been on stable for at least one release (and they will be for at least one more b/c of beta).
The others though I agree that it may be a little soon to move them to a hard error as they’re only sitting on beta. This does mean that they’re guaranteed to still give warnings for a whole release, but it’s probably good to let beta hit stable so anyone who only compiles on stable has a chance to catch up before we break nightly.
Although if the amount of code supporting these is blocking progress in other aspects, I could see making an exception and turning them to a hard error sooner. They will after all still have an entire cycle on stable as just warnings.
