Committing to a Rustfix Tool for All Epochs/Checkpoints Changes

[SimonSapin]

Epoch hygiene is good to avoid breakage when updating the compiler, but presumably any code base under active development may want to migrate eventually. The existence of rustfix should not be enough to skip considering how much impact a given proposed change would have on existing code bases. Some ideas like should be non-starters regardless of tooling. (For an extreme example, consider “replace <…> with […] for generics”.)

[Ixrec]

@SimonSapin @rpjohnst What do you feel would be a sufficient set of restrictions on epoch changes?

[withoutboats]

Some ideas like should be non-starters regardless of tooling. (For an extreme example, consider “replace <…> with […] for generics”.)

Can you lay out what you see as the reasons this example is a non starter? (I agree its a nonstarter, but it’d be helpful to get a better sense of your constraints).

[SimonSapin]

I wrote in https://github.com/rust-lang/rfcs/pull/2052#issuecomment-324357978 :

Of course, this RFC isn’t suggesting that such a course of action is a good one, just that it is possible to do without breakage. The policy around such changes is left as an open question.

[…]

These downsides are most problematic in cases that involve “breakage” if they were done without opt in. They indicate that, even if we do adopt checkpoints, we should use them judiciously.

I’d like the wording here to be stronger. I worry that the existence of the checkpoints mechanism in rustc is considered a “free pass” for proposing breaking changes. Since this RFC was opened I’ve seen multiple other RFCs and proposals that include breaking changes (to be included in the next checkpoint) like it’s no big deal.

I think this RFC should not leave the policy around this as a completely open question. No need to go into much details, but it should emphasize that making breaking changes are still not a step to take lightly. That they intrinsically cause a burden to maintainers of existing code (even though we take all steps to make that easier to deal with) which should be balanced against the expected benefits of a given change by guesstimating how much existing code would be affected. (For example, code using trait objects is probably more common that code using catch as an identifier.)

This is deliberately a bit vague. I think there should not be a checklist set in stone that says “if you do X and Y then your breaking change is fine”. It should be a case-by-case judgment call, where each proposal/RFC makes some effort at estimating the impact and arguing why similar benefits can’t be obtained without a breaking changes or with a different breaking change that would have less impact.

My point is that a hand-wavy proposal that stops at “we’ll just use an epoch” (or “an epoch + rustfix”) is not good enough.

[SimonSapin]

Can you lay out what you see as the reasons this example is a non starter? (I agree its a nonstarter, but it’d be helpful to get a better sense of your constraints).

The amount of existing code that would be impacted is too big. Even if rustfix would work in all but a small percentage of situations, a small percentage of a very large amount is still a large amount.

In a less extreme case, this estimated amount should be balanced against the expected benefits of the change.

Edit: even when it can be automated, no one wants to do a migration every two years that affects most files of a project.

[Ixrec]

When you put it like that, it seems so obvious I feel silly for asking the question.

I’d be on board with making “Why does this require an epoch/checkpoint?” a separate section in the RFC template that’s mandatory for any RFC proposing such a change. Maybe tomorrow I’ll try adding that to my dyn Trait RFC.

[killercup]

As the author of https://github.com/killercup/rustfix, I believe that having such a tool is very valuable to help with making sure code is idiomatic and reducing deprecation warnings, and even more awesome if it were to support fixes across epochs checkpoints.

At the same time, I’d be surprised if we were able to write auto-fixes for every change in a checkpoint—Rust is a surprisingly complex language with many nuances that make auto-fixes hard to get 100% right.

And just like “Code too verbose? Use an IDE” is not good for language design (IMHO), using a tool to justify breaking changes will make people angry the second it doesn’t work for their niche project generating code using an API definition, or even just when they are suddenly confronted with a 1000 line diff.

[kornel]

Swift had syntax migration tool. While it definitely helped to keep up with the changes, it wasn’t painless:

• Swift’s migration seemed to work in 95% of cases, but that still meant every non-trivial project ended up with some broken code and needed manual fixes. And it was always the worst few cases that confused the compiler, so compiler’s fix suggestions weren’t helping.

• Migration caused chaos in projects using feature branches. Project-wide syntax changes made pre-migration branches incompatible with post-migration branches. After migration you can’t cherry-pick or revert from old code, and you can’t even run the migration tool again on such mixed-version syntactically invalid code.

• The tool obviously couldn’t fix code it couldn’t see, so it missed commented-out code, files that were unfinished/temporarily disabled, helper scripts outside the main project, etc.

• Swift required migration of the whole project in one go, but such instant project-wide switchover was too hard to coordinate in large projects (where different components were maintained by different teams on their own schedule).

Fortunately Rust is easier to split into smaller creates (with potentially mixed epochs), so some of these problems won’t be as bad, but it’s good to keep in mind that automatic syntax fixes are not panacea.

[ahmedcharles]

I think rustfix should be a tool that fixes errors (like clang’s fixit) or deprecation warnings (other types of warnings are hard to fix in an automated way).

The issue with ‘migration tools’ is that they are necessarily a single step. If every increment of the epoch can only remove features which were deprecated (with alternatives) in the previous epoch, then all code can slowly remove deprecated features over time and once deprecation free, bump the epoch painlessly, since it’s guaranteed to compile cleanly with the same semantic meaning.

[comex]

Even so, having a tool to automatically switch from the deprecated features to the non-deprecated ones can make for a much nicer user experience than having to go through the code manually.

IMO, the existence of a tool should be necessary but not sufficient to justify a change. As @kornel described, even a ‘perfect’ migration tool (one that never required manual fixes) would not be a panacea, because of version control and things like commented-out/disabled code (and other reasons). Thus, a tool is not sufficient to justify otherwise highly disruptive changes; it should only slightly decrease the bar for disruptiveness, if at all. However, if a change is going to be made, the fact that a migration tool is feasible in Rust means that it’s vital to provide one. Not doing so feels like sloppy UX, literally from an emotional perspective: it doesn’t feel good to be made to do work you know the computer could do for you. Conversely, it feels great to have the computer do work you thought you might have to do yourself!

[vadimcn]

I’ve asked this in the RFC thread, but it did not get much attention there, so I’ll repeat here: had we considered solving at least some of the issues by improving compiler diagnostics?

For example, to address module paths learnability, we could have rustc try to look up unresolved items in the crate root scope and if module::Item can be resolved from there, emit a note informing user about that, along with suggestions on how to fix it: either use an absolute path (::module::Item) or import module into the current scope (use module).

[petrochenkov]

I wrote about this as well (https://github.com/rust-lang/rfcs/pull/2121#issuecomment-324736184).
There are very few diagnostics addressing the confusion points mentioned in module RFCs (and maybe that is the primary reason of why “module system is too confusing”?).

[repax]

Rustfix should obviously be tested against the widest range of code out there - perhaps by integrating with crater:

1. Build the old code.
2. Run rustfix.
3. Build the new code.
4. Compare.

A release candidate of rustfix could also be available for some period of time - before proceeding with deprecations - to allow parties with closed source code to test it and leave feedback.

[ahmedcharles]

Even so, having a tool to automatically switch from the deprecated features to the non-deprecated ones can make for a much nicer user experience than having to go through the code manually.

I believe that was the entire point of my post.

[est31]

Another big point against breaking changes is the teaching story. My university still has some teaching materials from 2004. Some of the screenshots are from netscape navigator! If they ever adopted Rust, they’d probably not update it for years to come, which means that students will never be able to get in touch with “modern” Rust if it changes significantly every 2-5 years.

Now you can argue that there are universities which still teach pascal, and that its more about the concepts, but that’s not the point. Students won’t start projects in pascal, they’ll (hopefully) start projects in Rust. And which Rust will they use? They one they’ve learned, following the path of least resistance. I don’t think this is of any help for consistency in the ecosystem.

Rust is a young language and is still very consistent. Any breaking change will lead to inconsistencies, so I think the cost of breaking changes is very very high, because it destroys this high degree of consistency, even if it just involves running an automated tool.

Also, Rust is not Swift. Swift is a language primarily designed for apple devices. Apple has enough control over the ecosystem to force coders to port their codebase to more modern versions of swift. They can just refuse support for old swift in newer versions of Xcode, and refuse code compiled with older Xcode versions to be submitted to the app store. Outside of app store apps, Swift is practically dead. So doing breaking changes while maintaining consistency is very easy for Swift. For Rust, its very hard. Rust is and will be used inside a much more diverse set of environments than Swift.

About requiring rustfix for any breaking change, I’m wondering how macros 2.0 will fit in there. I don’t think it will be possible to write a migration tool to migrate macro_rules! macros over to macros 2.0 that have exactly the same behaviour.

[johnthagen]

Rust is a young language and is still very consistent. Any breaking change will lead to inconsistencies, so I think the cost of breaking changes is very very high, because it destroys this high degree of consistency, even if it just involves running an automated tool.

The other side of this is that because Rust is young if something needs to be fixed eventually, now is the best time to do it before the inertia (and cost) is even greater.

[repax]

A central point of the whole epoch/checkpoint idea is that:

Existing code continues to compile, and crates can freely mix dependencies using different checkpoints.

You’re not forced to update your crate. Some concerns stated in this thread are a bit exaggerated.

[withoutboats]

The issue with ‘migration tools’ is that they are necessarily a single step. If every increment of the epoch can only remove features which were deprecated (with alternatives) in the previous epoch, then all code can slowly remove deprecated features over time and once deprecation free, bump the epoch painlessly, since it’s guaranteed to compile cleanly with the same semantic meaning.

This is exactly what we’ve guaranteed from the beginning! Code from the 2015 epoch that compiles without warnings will compile on the 2019 epoch.

A lot of this thread feels like retreading what we’ve already committed to about epochs, so I’m worried this isn’t getting communicated effectively. To reiterate:

• Crates from multiple epochs can be compiled together.
• If it compiles without warnings on epoch N, it compiles on epoch N + 1.
• We will provide a tool to automatically move your crate to the next epoch. We are considering how feasible it is to automate each deprecation we are considering as part of the decision.
• The epoch can only change surface syntax, not the core semantics of Rust.

[est31]

That’s a good point. I’m not generally opposed to epochs, but in my optimal world we’d have a couple of epochs and then leave the epoch system be and not add any more epochs after a certain point.

[Ixrec]

This is similar to what I had in mind. I don’t think we could ever commit to never discovering a new compelling reason to do an epoch, but we only have a handful of good reasons for one today, and we probably won’t discover any new ones until we’ve stabilized and/or implemented a bunch more features (which will take a long time). My assumption thus far has been that once either or both of the two epoch-using RFCs currently under discussion get accepted, we ensure a flawless rustfix workflow for them, and then–with the possible exception of the autoloading modules eRFC we’ve been “promised”–we probably won’t do any more epochal changes for the forseeable future. Not because there’s some kind of limit, but because we don’t yet know of any other epochal change worth doing.