FCP for various "future compatibility" warnings


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)




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

    • (no tracking #)
    • a745614f44d343cf40bd2a623d0b8d522547d570
    • 2015-11-26
    • 1.7
    • #19925
    • 3855fa99cad8412be5c2f322fa40a0d415d6cbd6
    • 2016-03-09
    • 1.9
    • #33242
    • 6057a7f18827f065668fcf22cfc0242de8f694b9
    • 2016-05-01
    • 1.10
    • #33243
    • 6057a7f18827f065668fcf22cfc0242de8f694b9
    • 2016-05-01
    • 1.10
    • #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.



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



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



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.



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


closed #11

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