NLL: must review all .nll.stderr files · Issue #49862 · rust-lang/rust (original) (raw)

#49861 checkpoints the state of NLL blindly. I made almost no attempt to check whether the content of each .nll.stderr file makes sense.

(I did sanity check a couple to just make sure that --compile-mode=nll seems like it is working, but even then I wouldn't call that skimming any sort of formal review.)

So, here's the issue: each instance of foo.nll.stderr represents a difference in the output from the AST-borrowck versus NLL borrowck.

Here are some reasons we might see different output:

The input file might be an error under lexical lifetimes but be accepted by rustc under NLL. Such cases are marked by either an empty foo.nll.stderr or a #[rustc_error] diagnostic output (see compiletest: compare-mode cannot handle mixed success + failure #49855 for an explanation of that).

Sometimes such a case just means that the test should be removed or converted to a run-pass test.
But most often, preserving the spirit of the original test in this case will require revising it in some way. Much of the Rust test suite was written assuming lexical lifetimes and test authors took short-cuts making use of this, e.g. by just taking a mutable borrow and never using it. We often should just fix such tests by adding a use of the mutable borrow at a "correct" point in the source code.

Both modes might reject the input, but NLL may emit a different set of error codes from AST borrowck. We need to review such cases to make sure the change in codes makes sense; and if it doesn't, then we should file a corresponding bug against NLL.
Both modes might reject the input, with the same error codes, but NLL may have different spans or other details in its diagnostic output. We need to review such cases and determine if the change in output includes an unacceptable degradation in quality; if so, then we need to file a bug against NLL (or, quite possibly, note the particular test in a pre-existing bug, since we already know that NLL has a large number of cases where its diagnostic output is not yet up-to-snuff).

In this issue, I am going to make a list of all of the .nll.stderr files added in #49861. The idea is that people can then volunteer to review that stderr output under NLL mode, comparing it to the stderr output under AST borrowck, and figure out which case above the test falls into.