Blindly checkpoint status of NLL mode ui tests
This takes the next (and potentially final?) step with #48879.
Namely, this PR got things to the point where I can successfully run `compiletest` on `src/test/ui` with `--compile-mode=nll`.
Here are the main pieces of it:
1. To figure out how to even run `compiletest` normally on the ui directory, I ran `x.py test -vv`, and then looked for the `compiletest` invocation that mentioned `src/test/ui`.
2. I took the aforementioned `compiletest` invocation and used it, adding `--compile-mode=nll` to the end. It had 170 failing cases.
3. Due to #49855, I had to edit some of the tests so that they fail even under NLL, via `#[rustc_error]`. That's the first commit. (Then goto 2 to double-check no such tests remain.)
4. I took the generated `build/target/test/foo.stderr` file for every case that failed, and blindly copied it to `src/test/foo.nll.stderr`. That's the second commit.
5. Goto 2 until there were no failing cases.
6. Remove any stamp files, and re-run `x.py test` to make sure that the edits and new `.nll.stderr` files haven't broken the pre-existing test suite.
add regression test for #16223 (NLL): use of collaterally moved value
Adds regression test for https://github.com/rust-lang/rust/issues/16223 which NLL fixes.
The current downside of this test is that it uses the `#![feature(box_patterns)]` and I haven't come up with a proper test that only uses the `#![feature(nll)]` - however, I don't know if this is even possible to test without `#![feature(box_syntax)]` or `#![feature(box_patterns)]`.
in which the non-shorthand patterns lint keeps its own counsel in macros
In issue #49588, Michael Lamparski pointed out a scenario in which the
non-shorthand-field-patterns lint could be triggered by a macro-expanded
pattern, in a way which was direly unwieldy for the macro author to guard
against and unreasonable to expect the macro user to take into account. We can
avoid this by not linting patterns that come from macro-expansions. Although
this entails accepting "false negatives" where the lint could genuinely improve
macro-templated code, avoiding the reported "true-but-super-annoying positive"
may be worth the trade? (Some precedent for these relative priorities exists as
no. 47775 (5985b0b0).)
Resolves#49588.
Use sort_by_cached_key where appropriate
A follow-up to https://github.com/rust-lang/rust/pull/48639, converting various slice sorting calls to `sort_by_cached_key` when the key functions are more expensive.
NOTE: I was careful to make each change in a manner that preserves the
existing diagnostic output (usually by ensuring that no lines were
added or removed). This means that the resulting source files are not
as nice to read as they were at the start. But we will have to review
these cases by hand anyway as follow-up work, so cleanup could
reasonably happen then (or not at all).
Modify compile-fail/E0389 error message WIP
This fixes#47388
cc @nikomatsakis @estebank
r? @nikomatsakis
Certain ui tests were failing locally. I'll check if the same happens here too.
Building for x86_64-unknown-linux-musl currently results in an executable lacking debug information for musl libc itself. If you request a backtrace in GDB while control flow is within musl – including sycalls made by musl – the result looks like:
#0 0x0000000000434b46 in __cp_end ()
#1 0x0000000000432dbd in __syscall_cp_c ()
#2 0x0000000000000000 in ?? ()
i.e. not very helpful. Adding --enable-debug resolves this, and --enable-optimize re-enables optimisations which default to off given the previous flag.
