Add a new "fix" mode #777
Add a new "fix" mode #777
Conversation
|
@Mark-Simulacrum I think this should be ready to merge. Let me know if you have any questions or need a walkthrough. |
Mark-Simulacrum
left a comment
There was a problem hiding this comment.
Can you say more about how the writable source will work in practice? Is it a requirement that before/after toolchains are executed on the same (mutated) directory? I think that's mostly the case today but long term I'd like to avoid it (for retrying builds etc).
|
Yea. It's actually a requirement that they don't share a mutated source directory. The intent for the edition testing is that the In the future if we want to extend this for more general-purpose I haven't really thought about how to make that safer. I don't recall if there is a way to do some kind of overlay fs mount that could just discard any modifications. Else I guess it will have to snapshot the source directory somehow? Or it could just delete and recreate it, but I worry about that being too expensive for git repos. |
This introduces a new "fix" mode to run `cargo fix`. This is primarily intended to support edition migration testing. This includes two related changes: - Adds the ability to change the CapLints behavior because setting CapLints interferes with how `cargo fix` works. - Sets the mount mode of the source directory to read-write because `cargo fix` inherently needs to be able to write to the source directory. It probably needs more work for general purpose `cargo fix` testing (non-edition) because otherwise it would need to rebuild the source directory between toolchains. I don't need that right now, so deferred that till later.
Yeah, the particular reason I was asking is that I'd like to decouple the start and end jobs more (so they're able to run on entirely different instances, etc.) so any dependency being added there is annoying. But this seems fine. I think that assumption mostly holds today - I'm a little worried about our retry logic (that's internal to the workers themselves), but I think it should be OK. At minimum nothing here seems directly wrong. Looks like lints are failing, ping me on Zulip once those are fixed and happy to queue it up for merging. |
This was recently added to nightly.
This introduces a new "fix" mode to run
cargo fix. This is primarily intended to support edition migration testing.This includes two related changes:
cargo fixworks.cargo fixinherently needs to be able to write to the source directory.It probably needs more work for general purpose
cargo fixtesting (non-edition) because otherwise it would need to rebuild the source directory between toolchains. I don't need that right now, so deferred that till later.The edition testing is intended to work with
cargo -Zfix-editionwhich performs the necessary actions to work in crater. More documentation (on the forge) will be coming once this is merged.