Stream: t-compiler/wg-meta

Topic: future-incompat planning


pnkfelix (Mar 13 2019 at 16:04, on Zulip):

hi @centril

centril (Mar 13 2019 at 16:04, on Zulip):

Hey!

pnkfelix (Mar 13 2019 at 16:04, on Zulip):

I'm going to transcribe our Discord conversation to a gist and then post a link to it.

pnkfelix (Mar 13 2019 at 16:05, on Zulip):

transcription will be linked here: https://gist.github.com/pnkfelix/a927bfd5c008e07e9757ac608c6c4443

pnkfelix (Mar 13 2019 at 16:08, on Zulip):

And now I will attempt to summarize, for the benefit of @WG-compiler-meta

pnkfelix (Mar 13 2019 at 16:08, on Zulip):

inspired by discussion of #58739 and a hypothetical future-incompat lint there

pnkfelix (Mar 13 2019 at 16:09, on Zulip):

@centril and I were were musing about some of the problems associated with shifting existing future-incompatibility lints from warnings into hard errors

pnkfelix (Mar 13 2019 at 16:10, on Zulip):

There are two problems that we discussed. Well, maybe three problems, depending on your point of view.

pnkfelix (Mar 13 2019 at 16:10, on Zulip):

First problem: We've been creating future-incompatibility lints, but we have not been establishing a plan/schedule for when they will eventually turn from warnings into hard errors.

pnkfelix (Mar 13 2019 at 16:11, on Zulip):

That seems like a policy question. Its probably one that is best handled by T-compiler and T-lang

pnkfelix (Mar 13 2019 at 16:12, on Zulip):

Second problem: The existing future-incompat lint structure lets developers #![allow(..)] such lints.

pnkfelix (Mar 13 2019 at 16:12, on Zulip):

Thus silencing them. Thus largely defeating their purpose.

pnkfelix (Mar 13 2019 at 16:12, on Zulip):

this may be especially problematic when one considers cargo and --cap-lints=allow.

pnkfelix (Mar 13 2019 at 16:13, on Zulip):

We almost certainly need to change that behavior in some fashion.

pnkfelix (Mar 13 2019 at 16:14, on Zulip):

but (and this is the third problem), I am not even sure how many stake-holders there are when it comes to such a change.

pnkfelix (Mar 13 2019 at 16:14, on Zulip):

Or, a rephrasing of the third-problem: Which teams/stakeholders to we need to pull into discussion of this matter?

pnkfelix (Mar 13 2019 at 16:15, on Zulip):

that last bit was what I think led @centril to suggest bringing this question to @WG-compiler-meta

centril (Mar 13 2019 at 16:15, on Zulip):

There's also probably a 4th problem: when we do move from warning=>deny=>error, who needs to approve? do we require team approval (which teams?), or just someone who reviews the crater regressions, the amount of time and then r+es?

centril (Mar 13 2019 at 16:17, on Zulip):

also cc @nikomatsakis :slight_smile:

Vadim Petrochenkov (Mar 13 2019 at 18:34, on Zulip):

For some background, the first "cycle" for compatibility warnings lasted for about 6 months, the second one for about 9 months, IIRC.
(I sent PRs promoting the warnings to deny-by-default and to errors in both cases.)
I planned to the third "cycle" to last for about a year (which seems like an ok timing for me in general), but the edition and other things happened, so it's more than 1.5 years now.

Vadim Petrochenkov (Mar 13 2019 at 18:35, on Zulip):

Of course, some lints were turned into errors out of the cycle because they blocked some other work or made it unwieldy.

nikomatsakis (Mar 14 2019 at 17:47, on Zulip):

We almost certainly need to change that behavior in some fashion.

see also https://github.com/rust-lang/rust/issues/34596 -- the best UI is a complex question.

nikomatsakis (Mar 14 2019 at 17:48, on Zulip):

Or, a rephrasing of the third-problem: Which teams/stakeholders to we need to pull into discussion of this matter?

I think perhaps the best thing would be to be somewhat "self-selecting". That is, we might try to arrange a meeting for a date in the future, and then advertise it widely and see who shows up and is interested. I think it would be a good topic for an RFC, ultimately.

nikomatsakis (Mar 14 2019 at 17:48, on Zulip):

Basically I imagine a short-lived working group focused on drafting a policy

nikomatsakis (Mar 14 2019 at 17:49, on Zulip):

not necessarily one that we go through the trouble to "list" on the page or anything

nikomatsakis (Mar 14 2019 at 17:49, on Zulip):

actually, if we adopted a "sprint-like structure"

nikomatsakis (Mar 14 2019 at 17:49, on Zulip):

this would be a good sprint goal for the meta WG

centril (Mar 14 2019 at 18:00, on Zulip):

I think T-Lang + T-Compiler are probably natural reviewers of an RFC in the end (at least for the non-cargo-ish parts)

centril (Mar 16 2019 at 08:49, on Zulip):

see also https://github.com/rust-lang/rust/issues/34596 -- the best UI is a complex question.

@nikomatsakis Looking at this, I think we should at least start with:
1. Make #![allow(the_incompat_lint)] have no effect and cap the lint at warn at most.
2. Extend this to --cap-lints=allow
1. can be done before 2.
As for not spamming people, first I think the annoyance is by design. I also think each future-compat lint should be emitted at least once. (e.g. don't say that the crate is broken, show why it is broken... because the crate author may be the same one as the dependency's author). That said, I think if we can reduce repetition that's good. However, I think we should not block on this because it may take much time and we should solve the more urgent problem first even if it temporarily is annoying.

centril (Mar 16 2019 at 08:51, on Zulip):

E.g. in the case of Servo and the type alias problem, this should encourage Servo's authors to file bugs against the third party crate such that the warning goes away.

Cem Karan (Mar 18 2019 at 13:47, on Zulip):

For some background, the first "cycle" for compatibility warnings lasted for about 6 months, the second one for about 9 months, IIRC.
(I sent PRs promoting the warnings to deny-by-default and to errors in both cases.)
I planned to the third "cycle" to last for about a year (which seems like an ok timing for me in general), but the edition and other things happened, so it's more than 1.5 years now.

How about doing this based on editions? As I understand the discussions around the 2019 roadmap, rust is now now going to be doing editions fairly regularly, correct? So, how about in edition N it's a warning, in edition N+1 it gets denied, and in edition N+2 it's a hard error? This will also give users an idea of how to prioritize any changes they need to make in their code bases based on where in the cycle a feature happens to be.

We can probably extend this to any sort of deprecation of features as well; that will allow rust to keep evolving, while allowing end users to keep up with the changes.

pnkfelix (Mar 18 2019 at 14:08, on Zulip):

I recently brought up a similar idea, of trying to tie incompat-shifts to edition releases, to SimonSapin. I wish I could remember the various objections they brought up, because I just remember instantly agreeing and saying it was a bad idea

pnkfelix (Mar 18 2019 at 14:09, on Zulip):

One concern is that it may be conflating very different things

pnkfelix (Mar 18 2019 at 14:10, on Zulip):

(e.g. consider changing coding style in order to match edition idioms, versus revising code in order to deal with anticipated hard errors predicts by future-incompat lints)

Cem Karan (Mar 18 2019 at 14:56, on Zulip):

@pnkfelix Could you point me to where those concerns are at? I'd like to know more, as well as see if we can come up with a systematic way of handling incompatible updates in the future.

Hrmmmmm.... maybe we need a working group on how to handle incompatible changes from a policy point of view...

pnkfelix (Mar 18 2019 at 15:01, on Zulip):

It was during a face-to-face conversation; I’ll try to poke Simon and ask them to boost my memory

Cem Karan (Mar 18 2019 at 19:10, on Zulip):

@pnkfelix Thanks.

nikomatsakis (Mar 19 2019 at 14:38, on Zulip):

I recently brought up a similar idea, of trying to tie incompat-shifts to edition releases, to SimonSapin. I wish I could remember the various objections they brought up, because I just remember instantly agreeing and saying it was a bad idea

for one thing I think the timeline is way too long

nikomatsakis (Mar 19 2019 at 14:38, on Zulip):

future incompatibility warnings are generally due to things like bug fixes

nikomatsakis (Mar 19 2019 at 14:38, on Zulip):

we are not going to wait until Rust 2021 (or whenever next edition occurs) to stabilize NLL

centril (Mar 19 2019 at 14:43, on Zulip):

Part of why I wanted to get a better handle on the C-future-compat lints was that I think we let them sit around for way too long even today; I'd like to shorten it overall

centril (Mar 19 2019 at 14:43, on Zulip):

It's fine to postpone based on crater runs ofc

centril (Mar 19 2019 at 14:43, on Zulip):

But if 3 months have passed and there are no crater regressions it should just be moved along

centril (Mar 19 2019 at 14:44, on Zulip):

I think of the schedules and whatnot as scheduled check-ins and guidelines

Cem Karan (Mar 19 2019 at 17:21, on Zulip):

for one thing I think the timeline is way too long

What sort of timeline were you imagining? That might suggest how to handle it.

Last update: Nov 18 2019 at 00:40UTC