FCP for various "future compatibility" warnings

[nikomatsakis]

I would like to propose that we move the following future compatibility warnings to FCP:

• (no issue, predates policy): private items in public APIs
• https://github.com/rust-lang/rust/issues/19925: transmute of fn items
• https://github.com/rust-lang/rust/issues/33242: unsized types within tuples
• https://github.com/rust-lang/rust/issues/33243: object-unsafe principal fragments
• https://github.com/rust-lang/rust/issues/33685: hr_lifetime_in_assoc_type future-compatibility warnings
  • 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
  • make into hard error (and close issue)

Thoughts?

[brson]

I tracked down the versions these were each introduced as warnings.

• PRIVATE_IN_PUBLIC
  • (no tracking #)
  • a745614f44d343cf40bd2a623d0b8d522547d570
  • 2015-11-26
  • 1.7
• TRANSMUTE_FROM_FN_ITEM_TYPES
  • #19925
  • 3855fa99cad8412be5c2f322fa40a0d415d6cbd6
  • 2016-03-09
  • 1.9
• UNSIZED_IN_TUPLES
  • #33242
  • 6057a7f18827f065668fcf22cfc0242de8f694b9
  • 2016-05-01
  • 1.10
• OBJECT_UNSAFE_FRAGMENT
  • #33243
  • 6057a7f18827f065668fcf22cfc0242de8f694b9
  • 2016-05-01
  • 1.10
• HR_LIFETIME_IN_ASSOC_TYPE
  • #33685
  • ccfb74e800eff83f316f55ecae337569d7e83ee4
  • 2016-03-22
  • 1.10

1.10 is beta and will be released July 7. 1.11 is nightly now, which will be released August 18.

[brson]

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.

[brson]

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.

[petrochenkov]

(no issue, predates policy): private items in public APIs

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

[nikomatsakis]

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

[nikomatsakis]

I believe the impact of all of these was quite small, as measured by crater

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

[nikomatsakis]

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.

Also: while there is some special-purpose code, I don’t think it’s gotten in my way yet

[alexcrichton]

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.

[nikomatsakis]

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

Seems fine to me. Let’s start with those.

[nikomatsakis]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.