Skip to content
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

NLL: Review compile-fail migrated tests #53351

Closed
21 of 49 tasks
davidtwco opened this issue Aug 14, 2018 · 7 comments
Closed
21 of 49 tasks

NLL: Review compile-fail migrated tests #53351

davidtwco opened this issue Aug 14, 2018 · 7 comments
Assignees
Labels
A-NLL Area: Non-lexical lifetimes (NLL) NLL-diagnostics Working towards the "diagnostic parity" goal T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@davidtwco
Copy link
Member

davidtwco commented Aug 14, 2018

As part of #53196, compile-fail tests were migrated to ui tests. In doing this, a handful of tests compile successfully in the NLL compare mode, but not in the normal AST compare mode. These tests were marked as "ignore on NLL compare mode" as there isn't an easy way to assert that a test compiles successfully in one compare mode and not in another. These tests are listed below and should be checked to make sure that it is correct that these tests ran successfully in NLL compare mode or if they have a bug:

(exact locations of tests have changed)

borrowck/

regions/

variance/

other

@davidtwco davidtwco added the A-NLL Area: Non-lexical lifetimes (NLL) label Aug 14, 2018
@davidtwco davidtwco added the NLL-diagnostics Working towards the "diagnostic parity" goal label Aug 14, 2018
@pnkfelix pnkfelix self-assigned this Aug 14, 2018
@pnkfelix
Copy link
Member

pnkfelix commented Aug 14, 2018

aassociated-types-subtyping-1.rs might be test weakness (in the sense of #51025), or an artifact of #47184, or both. In particular, I'm a little nervous about some of the code that is trying to encode some constraint also being clearly unreachable (due to loop { } blocks preceding them).

@pnkfelix
Copy link
Member

pnkfelix commented Aug 14, 2018

I finished going through the remainder of the list.

I have distributed the entries into the following buckets:

Glaring test weakness (in the sense of #51025); DONE: see PR #53369

For these, the test presumes lexical lifetimes (e.g. it writes let _w = &stuff; or let _w = &mut stuff; early on and assumes that borrows lasts until the end of the block). To fix this for NLL, we usually need to add one or more uses of some borrowed variable. (The use of a leading underscore on such variables is often a dead giveaway...) I've tried to link to the first such occurrence I noticed in the file.








let p: &isize = &*t0; // Freezes `*t0`

let p: &isize = &*t0; // Freezes `*t0`



let p: &isize = &*t0; // Freezes `*t0`




let b1 = &mut *b;

Possible test weakness #51025 (e.g., do we need to add some calls of the closures or object methods, or make code reachable?); (almost done, see PR #53407)

Update: adding calls is not needed; it suffices to merely add (no-op) references to the variables that hold the first closure immediately after the second one is defined, and you see the error then.

Update 2: I've covered all the cases except associated-types-subtyping-1.rs in PR #53407

let a: <T as Trait<'a>>::Type = loop { };

let c1 = to_fn_mut(|| x = 4);

let mut it = my_stuff.iter();


Fixed (at least somewhat) by NLL

For these cases, we should just add a #[rustc_error] to the fn main() (assuming the existing fn main() is trivial; if the fn main is not trivial, then rename it and add a trivial fn main)

fn pre_freeze_cond() {
// In this instance, the freeze is conditional and starts before
// the mut borrow.
let mut v: Box<_> = box 3;
let _w;
if cond() {
_w = &v;
}
borrow_mut(&mut *v); //~ ERROR cannot borrow
}

fn pre_freeze() {
// In this instance, the freeze starts before the mut borrow.
let mut v: Box<_> = box 3;
let _w = &v;
borrow_mut(&mut *v); //~ ERROR cannot borrow
}

Have our rvalue lifetime rules changed...?

I skimmed over this test but I cannot immediately tell whether NLL should have changed anything here... I'll need to read it again with a fresh pair of eyes (and perhaps review some of the doc and/or blog posts discussing our rvalue lifetime rules...)

pub fn main() {
let _x = arg(&AddFlags(1)); //~ ERROR value does not live long enough
let _x = AddFlags(1).get(); //~ ERROR value does not live long enough
let _x = &*arg(&AddFlags(1)); //~ ERROR value does not live long enough
let ref _x = *arg(&AddFlags(1)); //~ ERROR value does not live long enough
let &ref _x = arg(&AddFlags(1)); //~ ERROR value does not live long enough
let _x = AddFlags(1).get(); //~ ERROR value does not live long enough
let Box { f: _x } = Box { f: AddFlags(1).get() }; //~ ERROR value does not live long enough
}

Known bug

These cases all fall into some form of #47184

I link to the first obvious example of some type ascription that is currently unchecked:

let _c: <T as Trait<'a>>::Type = a;

let x: &'static _ = &|| { let z = 3; z }; //~ ERROR does not live long enough

Foo::<'a, 'b>::xmute(u) //~ ERROR lifetime bound not satisfied

Finally, all of the tests in regions/ and all of the tests in variance/ use type ascription (in arguably advanced ways) as a way to encode the desired (potentially subtle checks).

I think all of these should be fixed when #47184 is fixed, or potentially sooner as subtasks of that bug are completed.

Already using -Z borrowck=XXX in a different revision.

In this case, the test is already requesting some form of MIR-borrowck via explicit compiler flags and presumably does not need to go through the compare-mode=nll system. HOWEVER, there are instances of this in the test suite where the only reason we used the revision system and compiler flags is that those tests predate the compare-mode=nll. So we should consider trying to update them anyway, if possible.

//[mir]compile-flags: -Z borrowck=compare

@pnkfelix
Copy link
Member

There isn't that much left to do here in the short term; IMO all of the regions/ and variance/ are effectively blocked on #47184 -- or at least, I do not think we should invest any effort trying to find a different way to encode those tests. All such effort should be spent instead on addressing #47184, and then once that is addressed, we should be able to remove the // ignore-test-compare-nll on those files with relative ease.

I think once you remove those files and the others blocked by #47184, then there's only maybe nine or tests left to be either investigated or updated.

@pnkfelix
Copy link
Member

(having said that, I'm unassigning myself since I am not sure I will have time during the remainder of this week to investigate the remaining tests here.)

@pnkfelix pnkfelix removed their assignment Aug 14, 2018
bors added a commit that referenced this issue Aug 17, 2018
…e-fail-tests-more-robust-wrt-nll, r=davidtwco

Make some ported cfail tests robust w.r.t. NLL

Updated the most glaring instances of weak tests w.r.t. NLL that came from #53196.

See also the bulletpoint list on #53351.
@nikomatsakis nikomatsakis added this to the Rust 2018 RC milestone Aug 27, 2018
@nikomatsakis nikomatsakis added WG-compiler-nll T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. and removed WG-compiler-nll labels Aug 27, 2018
@pnkfelix
Copy link
Member

It might be good to figure out some way to fold this issue (#53351) into #52663, or open up a new issue that covers the remaining cases in the two issues.

Also, if we do one of those big reviews, we may also want to wait until #53764 is done.

@pnkfelix pnkfelix self-assigned this Sep 11, 2018
@pnkfelix
Copy link
Member

assigning to self so that remember to factor this into smaller issues that can be individually triaged.

@pnkfelix
Copy link
Member

I've decided we need a third big round of review, which is filed as #54528

While it might make sense to try to resolve this issue (#53351) before attacking #54528, it probably makes just as much sense to focus attention fully on #54528 itself.

So I'm closing this issue in favor of #54528.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-NLL Area: Non-lexical lifetimes (NLL) NLL-diagnostics Working towards the "diagnostic parity" goal T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants