FCP for various "future compatibility" warnings


#1

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

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?


#2

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.


#3

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.


#4

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.


#5

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


#6

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


#7

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


#8

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


#9

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.


#10

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