-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Blindly checkpoint status of NLL mode ui tests #49861
Conversation
…ing NLL. 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).
(rust_highfive has picked a reviewer for you, use r? to override) |
Landing this doesn't make any sense without the tidy fix in #49844, which is the "real" first commit in this PR. That commit is pretty trivial, so it might make most sense to close #49844 and just focus on landing this. But I'll let @nikomatsakis decide about that. |
r=me -- maybe a good candidate for p=1 too |
@bors r+ p=1 |
📌 Commit 746d63a has been approved by |
(well, the p=1 isn't going to stop people from adding follow-on PR's that regress things, because we have not yet added anything to our continuous integration (i.e. bors) that runs compiletest under compare-more=nll... but hopefully that will come soon...) |
@bors p=45 |
…tsakis 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.
☀️ Test successful - status-appveyor, status-travis |
This takes the next (and potentially final?) step with #48879.
Namely, this PR got things to the point where I can successfully run
compiletest
onsrc/test/ui
with--compile-mode=nll
.Here are the main pieces of it:
compiletest
normally on the ui directory, I ranx.py test -vv
, and then looked for thecompiletest
invocation that mentionedsrc/test/ui
.compiletest
invocation and used it, adding--compile-mode=nll
to the end. It had 170 failing cases.#[rustc_error]
. That's the first commit. (Then goto 2 to double-check no such tests remain.)build/target/test/foo.stderr
file for every case that failed, and blindly copied it tosrc/test/foo.nll.stderr
. That's the second commit.x.py test
to make sure that the edits and new.nll.stderr
files haven't broken the pre-existing test suite.