Want -Z borrowck=migrate to test planning migration to non-lexical lifetimes · Issue #46908 · rust-lang/rust (original) (raw)

Task list:

• Change MIR-borrowck (aka NLL) to so that it first buffers all errors and then emits them in a post-pass over the buffer at the end.
• Add a pure mode to AST-borrowck where it does not have any side-effects (namely no I/O related to emitting errors), but rather just returns a boolean based on whether any errors occurred or not.
• Add -Z borrowck=migrate; it first runs NLL. If the code passes, then we're done. If there were errors buffered, then before emitting its buffered errors, it runs AST-borrowck in the aforementioned pure mode. If AST-borrowck signals any error, then emit the NLL errors. If the AST-borrowck accepts the code, then downgrade all the NLL errors to warnings and then emit them.
• Make sure the docs and/or diagnostics indicate that the NLL errors-downgraded-to-warnings represent future-compatibility hazards in the developer's code and will become hard errors in the future.

Original bug report follows:

We are currently planning on an initial deployment of non-lexical lifetimes (NLL) via an opt-in feature flag #![feature(nll)] (which actually just landed last night, woo hoo)!

However, our plan is not to just choose some arbitrary point in the future and making #![feature(nll)] the default with no warning.

In particular, there is some code that is accepted today under AST borrowck that NLL rejects. So we need a migration path.

Luckily, we already have the pieces in place to run both AST-borrowck and MIR-borrowck (aka NLL). So we can make that part of the migration path.

In particular, lets add a -Z borrowck=migrate flag. When its turned on, we run both borrow checkers (much the same way that -Z borrowck=compare does today). But now we consider both results when reporting errors:

• If both AST- and MIR-borrowck accept the code, then accept (of course),
• If both AST- and MIR-borrowck reject the code, then reject (ibid),
• If AST-borrowck rejects the code and MIR-borrowck accepts, then accept. (Indeed, this is the point of NLL, to start accepting a broader swath of code.)
• If AST-borrowck accepts the code and MIR-borrowck rejects, then warn, and point out that the warning will become a hard error in the future.

Of course the devil is in the details here. In particular, the above breakdown acts like one can always meaningfully relate the errors generated by AST- and MIR-borrowck, but the reality is that the two will differ in their reports.

To avoid presenting duplicated sets of errors from both AST- and MIR-borrowck in the cases where they both reject, my plan is to use the error code numbers as an approximation to whether an error was signaled or not from AST-borrowck before deciding whether to report it or treat it as a warning from MIR-borrowck.