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

MIR-borrowck: behavior around Box<T> is different from AST borrowck #45696

Closed
arielb1 opened this issue Nov 1, 2017 · 18 comments · Fixed by #52782
Closed

MIR-borrowck: behavior around Box<T> is different from AST borrowck #45696

arielb1 opened this issue Nov 1, 2017 · 18 comments · Fixed by #52782
Assignees
Labels
A-borrow-checker Area: The borrow checker A-NLL Area: Non-lexical lifetimes (NLL) NLL-complete Working towards the "valid code works" goal
Milestone

Comments

@arielb1
Copy link
Contributor

arielb1 commented Nov 1, 2017

MIR borrowck treats Box<T> differently from AST borrowck (not that AST borrowck is terribly consistent there), for example, in the (simplified) test for #17263:

struct Foo { a: isize, b: isize }

fn main() {
    let mut x: Box<_> = Box::new(Foo { a: 1, b: 2 });
    let (_a, _b) = (&mut x.a, &mut x.b);
    //~^ ERROR cannot borrow `x` (via `x.b`) as mutable more than once at a time
    //~| NOTE first mutable borrow occurs here (via `x.a`)
    //~| NOTE second mutable borrow occurs here (via `x.b`)

    let mut foo: Box<_> = Box::new(Foo { a: 1, b: 2 });
    let (_c, _d) = (&mut foo.a, &foo.b);
    //~^ ERROR cannot borrow `foo` (via `foo.b`) as immutable
    //~| NOTE mutable borrow occurs here (via `foo.a`)
    //~| NOTE immutable borrow occurs here (via `foo.b`)
}
//~^ NOTE first borrow ends here
//~^^ NOTE mutable borrow ends here

AST borrowck reports an error on both lines, but MIR borrowck lets the code pass:

error[E0499]: cannot borrow `x` (via `x.b`) as mutable more than once at a time (Ast)
  --> ../src/test/compile-fail/issue-17263.rs:15:36
   |
15 |     let (_a, _b) = (&mut x.a, &mut x.b);
   |                          ---       ^^^ second mutable borrow occurs here (via `x.b`)
   |                          |
   |                          first mutable borrow occurs here (via `x.a`)
...
25 | }
   | - first borrow ends here

error[E0502]: cannot borrow `foo` (via `foo.b`) as immutable because `foo` is also borrowed as mutable (via `foo.a`) (Ast)
  --> ../src/test/compile-fail/issue-17263.rs:21:34
   |
21 |     let (_c, _d) = (&mut foo.a, &foo.b);
   |                          -----   ^^^^^ immutable borrow occurs here (via `foo.b`)
   |                          |
   |                          mutable borrow occurs here (via `foo.a`)
...
25 | }
   | - mutable borrow ends here

error: aborting due to 2 previous errors

This should be investigated and solved

@arielb1 arielb1 added A-borrow-checker Area: The borrow checker WG-compiler-nll labels Nov 1, 2017
@nikomatsakis
Copy link
Contributor

I think we have to decide how we are going to handle Box<T> in MIR borrowck. I would prefer not to introduce hacks into borrowck the way we did in the AST -- if we're going to impose some limitations on Box<T>, I would prefer to do it in the MIR lowering phase (e.g., by lowering let x = &mut box.foo more faithfully into something that uses the DerefMut impl).

What do you think @arielb1 ? I imagine this will cause more backwards incompatibility on the various corner cases that AST borrow check gets wrong, is one concern.

@nikomatsakis
Copy link
Contributor

An alternative of course is to restore the "full knowledge" to Box<T> -- it's already somewhat special -- with the assumption that we will someday allow user-written types to "opt-in" to such semantics.

@arielb1
Copy link
Contributor Author

arielb1 commented Nov 16, 2017

@nikomatsakis

I would prefer to have "full DerefPure" semantics for Box. We already have fairly builtin move semantics, and the AST borrowck semantics are terrible in a few places.

@arielb1 arielb1 added this to the NLL prototype milestone Nov 16, 2017
@nikomatsakis
Copy link
Contributor

@arielb1 I agree. It seems like then there is not a lot of work to do here, right? Or are there places where MIR borrowck enforces rules that are too strict?

@arielb1
Copy link
Contributor Author

arielb1 commented Nov 16, 2017

@nikomatsakis

I think MIR borrowck currently has an even stupider version of the Box borrow rules, which needs to be removed.

@nikomatsakis
Copy link
Contributor

I'm going to try writing out some tests here in the comments and their current behavior.


Access field 1 while field 0 is borrowed

fn main() {
    let mut data = Box::new((1, 2));
    let p = &data.0;
    data.1 += 1;
}

This gives an Ast error, but no Mir error, as expected.


Drop box while field 0 is borrowed

fn main() {
    let mut data = Box::new((1, 2));
    let p = &data.0;
    drop(data);
    println!("{}", p);
}

This gives an error in both AST / MIR, as expected.


Access field 1 when field 0 is borrowed

fn main() {
    let data = Box::new((format!("Hello"), format!("World")));
    drop(data.0);
    println!("{}", data.1);
}

This gives an error only in AST, as expected.


Return reborrowed mutable ref in field 0

fn return_borrowed<'a>(x: Box<(&'a mut u32, &mut u32)>) -> &'a mut u32 {
    &mut *x.0
}

fn main() {
}

This gives an error only in MIR. Seems wrong.

(Ironically, both AST and MIR seem wrong here. That is, to be consistent, AST should error, but doesn't. And MIR should not, but does.)


@nikomatsakis
Copy link
Contributor

The last error is of course nikomatsakis/nll-rfc#40. I still like the dangly paths answer there, but I do appreciate and understand @arielb1's trepidation. Perhaps we just do some kind of limited variant hard-coded to Box for now. =)

@arielb1
Copy link
Contributor Author

arielb1 commented Nov 18, 2017

@nikomatsakis

The last error is of course nikomatsakis/nll-rfc#40

It is. However, luckily for us, Box is DerefPure, which means that we "known" its destructor can't access the interior (after all, the interior could have been moved), so this looks like a clearer place to special-case.

arielb1 added a commit to arielb1/rust that referenced this issue Dec 6, 2017
Fixes rust-lang#44831.
Fixes rust-lang#44834.
Fixes rust-lang#45537.
Fixes rust-lang#45696 (by implementing DerefPure semantics, which is what we want
going forward).
bors added a commit that referenced this issue Dec 6, 2017
MIR borrowck: implement union-and-array-compatible semantics

Fixes #44831.
Fixes #44834.
Fixes #45537.
Fixes #45696 (by implementing DerefPure semantics, which is what we want going forward).

r? @nikomatsakis
@Mark-Simulacrum
Copy link
Member

Reopening; it seems this has regressed, the following code snippet doesn't compile with MIR but does with AST borrowck; I think it's the same issue as described here (i.e., different semantics for Box).

#![feature(nll)]

fn foo(x: Box<&mut i32>) -> &mut i32 {
    *x
}

fn main() {}

@arielb1
Copy link
Contributor Author

arielb1 commented Jul 15, 2018

@Mark-Simulacrum

This is just nikomatsakis/nll-rfc#40, or on the AST side #31567.

@pnkfelix
Copy link
Member

either way we really need some issue open on the rust-lang/rust repo to track this, and unless I'm missing something, currently both #31567 and #45696 are closed.

So I'm reopening this (which I think @Mark-Simulacrum meant to do but forgot?)

@pnkfelix pnkfelix reopened this Jul 25, 2018
@nikomatsakis nikomatsakis added the A-NLL Area: Non-lexical lifetimes (NLL) label Jul 25, 2018
@pnkfelix pnkfelix added the NLL-complete Working towards the "valid code works" goal label Jul 25, 2018
@pnkfelix
Copy link
Member

I'm going to try to look at this today

@pnkfelix pnkfelix self-assigned this Jul 26, 2018
@pnkfelix
Copy link
Member

I think I have a specialized fix specific to Box that I'm reasonably confident in.

It is this commit: pnkfelix@596f363

I hope to put up a PR tomorrow.

@pnkfelix
Copy link
Member

Okay pnkfelix/rust@596f363 isn't quite right. Or at least, I want to make sure we handle the following three cases correctly: https://play.rust-lang.org/?gist=16b3dc1280f5becafae18e94790c6fc4&version=nightly&mode=debug&edition=2015

@pnkfelix
Copy link
Member

Well its great that I found that bug; it forced me to reconsider my solution in a number of ways and I found a different technique that I like a lot more than the commit I made yesterday.

New commit: pnkfelix/rust@bcb19fc

@pnkfelix
Copy link
Member

but oops I really need to get better at testing stuff first. Sigh.

@pnkfelix
Copy link
Member

(okay now PR #52782 is a change I'm pretty confident in. And as a bonus it also passes the test suite.)

cramertj added a commit to cramertj/rust that referenced this issue Aug 2, 2018
…or-box, r=eddyb

[NLL] Dangly paths for box

Special-case `Box` in `rustc_mir::borrow_check`.

Since we know dropping a box will not access any `&mut` or `&` references, it is safe to model its destructor as only touching the contents *owned* by the box.

----

There are three main things going on here:

1. The first main thing, this PR is fixing a bug in NLL where `rustc` previously would issue a diagnostic error in a case like this:
```rust
fn foo(x: Box<&mut i32>) -> &mut i32 { &mut **x }
```

such code was accepted by the AST-borrowck in the past, but NLL was rejecting it with the following message ([playground](https://play.rust-lang.org/?gist=13c5560f73bfb16d6dab3ceaad44c0f8&version=nightly&mode=release&edition=2015))
```
error[E0597]: `**x` does not live long enough
 --> src/main.rs:3:40
  |
3 | fn foo(x: Box<&mut i32>) -> &mut i32 { &mut **x }
  |                                        ^^^^^^^^ - `**x` dropped here while still borrowed
  |                                        |
  |                                        borrowed value does not live long enough
  |
note: borrowed value must be valid for the anonymous lifetime rust-lang#1 defined on the function body at 3:1...
 --> src/main.rs:3:1
  |
3 | fn foo(x: Box<&mut i32>) -> &mut i32 { &mut **x }
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error
```

2. The second main thing: The reason such code was previously rejected was because NLL (MIR-borrowck) incorporates a fix for issue rust-lang#31567, where it models a destructor's execution as potentially accessing any borrows held by the thing being destructed. The tests with `Scribble` model this, showing that the compiler now catches such unsoundness.

However, that fix for issue rust-lang#31567 is too strong, in that NLL (MIR-borrowck) includes `Box` as one of the types with a destructor that potentially accesses any borrows held by the box. This thus was the cause of the main remaining discrepancy between AST-borrowck and MIR-borrowck, as documented in issue rust-lang#45696, specifically in [the last example of this comment](rust-lang#45696 (comment)), which I have adapted into the `fn foo` shown above.

We did close issue rust-lang#45696 back in December of 2017, but AFAICT that example was not fixed by PR rust-lang#46268. (And we did not include a test, etc etc.)

This PR fixes that case, by trying to model the so-called `DerefPure` semantics of `Box<T>` when we traverse the type of the input to `visit_terminator_drop`.

3. The third main thing is that during a review of the first draft of this PR, @matthewjasper pointed out that the new traversal of `Box<T>` could cause the compiler to infinite loop. I have adjusted the PR to avoid this (by tracking what types we have previously seen), and added a much needed test of this somewhat odd scenario. (Its an odd scenario because the particular case only arises for things like `struct A(Box<A>);`, something which cannot be constructed in practice.)

Fix rust-lang#45696.
cramertj added a commit to cramertj/rust that referenced this issue Aug 2, 2018
…or-box, r=eddyb

[NLL] Dangly paths for box

Special-case `Box` in `rustc_mir::borrow_check`.

Since we know dropping a box will not access any `&mut` or `&` references, it is safe to model its destructor as only touching the contents *owned* by the box.

----

There are three main things going on here:

1. The first main thing, this PR is fixing a bug in NLL where `rustc` previously would issue a diagnostic error in a case like this:
```rust
fn foo(x: Box<&mut i32>) -> &mut i32 { &mut **x }
```

such code was accepted by the AST-borrowck in the past, but NLL was rejecting it with the following message ([playground](https://play.rust-lang.org/?gist=13c5560f73bfb16d6dab3ceaad44c0f8&version=nightly&mode=release&edition=2015))
```
error[E0597]: `**x` does not live long enough
 --> src/main.rs:3:40
  |
3 | fn foo(x: Box<&mut i32>) -> &mut i32 { &mut **x }
  |                                        ^^^^^^^^ - `**x` dropped here while still borrowed
  |                                        |
  |                                        borrowed value does not live long enough
  |
note: borrowed value must be valid for the anonymous lifetime rust-lang#1 defined on the function body at 3:1...
 --> src/main.rs:3:1
  |
3 | fn foo(x: Box<&mut i32>) -> &mut i32 { &mut **x }
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error
```

2. The second main thing: The reason such code was previously rejected was because NLL (MIR-borrowck) incorporates a fix for issue rust-lang#31567, where it models a destructor's execution as potentially accessing any borrows held by the thing being destructed. The tests with `Scribble` model this, showing that the compiler now catches such unsoundness.

However, that fix for issue rust-lang#31567 is too strong, in that NLL (MIR-borrowck) includes `Box` as one of the types with a destructor that potentially accesses any borrows held by the box. This thus was the cause of the main remaining discrepancy between AST-borrowck and MIR-borrowck, as documented in issue rust-lang#45696, specifically in [the last example of this comment](rust-lang#45696 (comment)), which I have adapted into the `fn foo` shown above.

We did close issue rust-lang#45696 back in December of 2017, but AFAICT that example was not fixed by PR rust-lang#46268. (And we did not include a test, etc etc.)

This PR fixes that case, by trying to model the so-called `DerefPure` semantics of `Box<T>` when we traverse the type of the input to `visit_terminator_drop`.

3. The third main thing is that during a review of the first draft of this PR, @matthewjasper pointed out that the new traversal of `Box<T>` could cause the compiler to infinite loop. I have adjusted the PR to avoid this (by tracking what types we have previously seen), and added a much needed test of this somewhat odd scenario. (Its an odd scenario because the particular case only arises for things like `struct A(Box<A>);`, something which cannot be constructed in practice.)

Fix rust-lang#45696.
bors added a commit that referenced this issue Aug 2, 2018
…ddyb

[NLL] Dangly paths for box

Special-case `Box` in `rustc_mir::borrow_check`.

Since we know dropping a box will not access any `&mut` or `&` references, it is safe to model its destructor as only touching the contents *owned* by the box.

----

There are three main things going on here:

1. The first main thing, this PR is fixing a bug in NLL where `rustc` previously would issue a diagnostic error in a case like this:
```rust
fn foo(x: Box<&mut i32>) -> &mut i32 { &mut **x }
```

such code was accepted by the AST-borrowck in the past, but NLL was rejecting it with the following message ([playground](https://play.rust-lang.org/?gist=13c5560f73bfb16d6dab3ceaad44c0f8&version=nightly&mode=release&edition=2015))
```
error[E0597]: `**x` does not live long enough
 --> src/main.rs:3:40
  |
3 | fn foo(x: Box<&mut i32>) -> &mut i32 { &mut **x }
  |                                        ^^^^^^^^ - `**x` dropped here while still borrowed
  |                                        |
  |                                        borrowed value does not live long enough
  |
note: borrowed value must be valid for the anonymous lifetime #1 defined on the function body at 3:1...
 --> src/main.rs:3:1
  |
3 | fn foo(x: Box<&mut i32>) -> &mut i32 { &mut **x }
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error
```

2. The second main thing: The reason such code was previously rejected was because NLL (MIR-borrowck) incorporates a fix for issue #31567, where it models a destructor's execution as potentially accessing any borrows held by the thing being destructed. The tests with `Scribble` model this, showing that the compiler now catches such unsoundness.

However, that fix for issue #31567 is too strong, in that NLL (MIR-borrowck) includes `Box` as one of the types with a destructor that potentially accesses any borrows held by the box. This thus was the cause of the main remaining discrepancy between AST-borrowck and MIR-borrowck, as documented in issue #45696, specifically in [the last example of this comment](#45696 (comment)), which I have adapted into the `fn foo` shown above.

We did close issue #45696 back in December of 2017, but AFAICT that example was not fixed by PR #46268. (And we did not include a test, etc etc.)

This PR fixes that case, by trying to model the so-called `DerefPure` semantics of `Box<T>` when we traverse the type of the input to `visit_terminator_drop`.

3. The third main thing is that during a review of the first draft of this PR, @matthewjasper pointed out that the new traversal of `Box<T>` could cause the compiler to infinite loop. I have adjusted the PR to avoid this (by tracking what types we have previously seen), and added a much needed test of this somewhat odd scenario. (Its an odd scenario because the particular case only arises for things like `struct A(Box<A>);`, something which cannot be constructed in practice.)

Fix #45696.
@pnkfelix
Copy link
Member

pnkfelix commented Nov 6, 2018

see also some follow-up discussion here #43234 (comment)

Centril added a commit to Centril/rust that referenced this issue Sep 25, 2019
Centril added a commit to Centril/rust that referenced this issue Sep 26, 2019
Centril added a commit to Centril/rust that referenced this issue Sep 26, 2019
JohnTitor referenced this issue in JohnTitor/rust Feb 1, 2021
…chenkov

Move some tests to more reasonable directories - 3

cc rust-lang#73494
r? `@petrochenkov`

https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-56202.rs <sup>https://github.com/rust-lang/rust/issues/56202</sup>: traits 1.008
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-69841.rs <sup>https://github.com/rust-lang/rust/issues/69841</sup>: for-loop-while 1.014
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-10763.rs <sup>https://github.com/rust-lang/rust/issues/10763</sup>: extern 1.016
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-50599.rs <sup>https://github.com/rust-lang/rust/issues/50599</sup>: resolve 1.018
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-6128.rs <sup>https://github.com/rust-lang/rust/issues/6128</sup>: traits 1.043
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-20616-8.rs <sup>https://github.com/rust-lang/rust/issues/20616</sup>: parser 1.045
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-46553.rs <sup>https://github.com/rust-lang/rust/issues/46553</sup>: consts 1.081
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-33140-hack-boundaries.rs <sup>https://github.com/rust-lang/rust/issues/33140</sup>: traits 1.101
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-25826.rs <sup>https://github.com/rust-lang/rust/issues/25826</sup>: consts 1.108
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-56488.rs <sup>https://github.com/rust-lang/rust/issues/56488</sup>: traits 1.110
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-58856-1.rs <sup>https://github.com/rust-lang/rust/issues/58856</sup>: parser 1.133
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-57819.rs <sup>https://github.com/rust-lang/rust/issues/57819</sup>: parser 1.138
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-54348.rs <sup>https://github.com/rust-lang/rust/issues/54348</sup>: consts 1.155
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-14309.rs <sup>https://github.com/rust-lang/rust/issues/14309</sup>: lint 1.160
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-4446.rs <sup>https://github.com/rust-lang/rust/issues/4446</sup>: threads-sendsync 1.203
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-53675-a-test-called-panic.rs <sup>https://github.com/rust-lang/rust/issues/53675</sup>: test-attrs 1.211
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-40231-2.rs <sup>https://github.com/rust-lang/rust/issues/40231</sup>: consts 1.213
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-22037.rs <sup>https://github.com/rust-lang/rust/issues/22037</sup>: associated-types 1.214
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-59029-2.rs <sup>https://github.com/rust-lang/rust/issues/59029</sup>: traits 1.219
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-18425.rs <sup>https://github.com/rust-lang/rust/issues/18425</sup>: consts 1.237
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-6157.rs <sup>https://github.com/rust-lang/rust/issues/6157</sup>: regions 1.238
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-33819.rs <sup>https://github.com/rust-lang/rust/issues/33819</sup>: borrowck 1.280
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-3683.rs <sup>https://github.com/rust-lang/rust/issues/3683</sup>: traits 1.283
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-8709.rs <sup>https://github.com/rust-lang/rust/issues/8709</sup>: macros 1.291
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-20616-9.rs <sup>https://github.com/rust-lang/rust/issues/20616</sup>: parser 1.293
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-64732.rs <sup>https://github.com/rust-lang/rust/issues/64732</sup>: parser 1.296
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-18655.rs <sup>https://github.com/rust-lang/rust/issues/18655</sup>: associated-types 1.305
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-32947.rs <sup>https://github.com/rust-lang/rust/issues/32947</sup>: simd 1.322
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-57198.rs <sup>https://github.com/rust-lang/rust/issues/57198</sup>: parser 1.342
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-10764-rpass.rs <sup>https://github.com/rust-lang/rust/issues/10764</sup>: extern 1.392
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-73541-2.rs <sup>https://github.com/rust-lang/rust/issues/73541</sup>: async-await 1.422
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-7970b.rs <sup>https://github.com/rust-lang/rust/issues/7970</sup>: parser 1.439
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-57684.rs <sup>https://github.com/rust-lang/rust/issues/57684</sup>: parser 1.512
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-33264.rs <sup>https://github.com/rust-lang/rust/issues/33264</sup>: llvm-asm 1.523
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-65284-suggest-generic-trait-bound.rs <sup>https://github.com/rust-lang/rust/issues/65284</sup>: suggestions 1.647
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-17458.rs <sup>https://github.com/rust-lang/rust/issues/17458</sup>: consts 1.711
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-56762.rs <sup>https://github.com/rust-lang/rust/issues/56762</sup>: consts 1.787
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-2216.rs <sup>https://github.com/rust-lang/rust/issues/2216</sup>: for-loop-while 1.856
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-45696-scribble-on-boxed-borrow.rs <sup>https://github.com/rust-lang/rust/issues/45696</sup>: nll 2.009
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-46036.rs <sup>https://github.com/rust-lang/rust/issues/46036</sup>: nll 2.059

`@petrochenkov` Can you put a place holder (like `N/A`) for tests without GitHub issues? It is a lot easier to parse fixed sized rows.
henryboisdequin referenced this issue in henryboisdequin/rust Feb 1, 2021
…chenkov

Move some tests to more reasonable directories - 3

cc rust-lang#73494
r? ``@petrochenkov``

https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-56202.rs <sup>https://github.com/rust-lang/rust/issues/56202</sup>: traits 1.008
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-69841.rs <sup>https://github.com/rust-lang/rust/issues/69841</sup>: for-loop-while 1.014
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-10763.rs <sup>https://github.com/rust-lang/rust/issues/10763</sup>: extern 1.016
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-50599.rs <sup>https://github.com/rust-lang/rust/issues/50599</sup>: resolve 1.018
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-6128.rs <sup>https://github.com/rust-lang/rust/issues/6128</sup>: traits 1.043
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-20616-8.rs <sup>https://github.com/rust-lang/rust/issues/20616</sup>: parser 1.045
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-46553.rs <sup>https://github.com/rust-lang/rust/issues/46553</sup>: consts 1.081
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-33140-hack-boundaries.rs <sup>https://github.com/rust-lang/rust/issues/33140</sup>: traits 1.101
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-25826.rs <sup>https://github.com/rust-lang/rust/issues/25826</sup>: consts 1.108
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-56488.rs <sup>https://github.com/rust-lang/rust/issues/56488</sup>: traits 1.110
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-58856-1.rs <sup>https://github.com/rust-lang/rust/issues/58856</sup>: parser 1.133
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-57819.rs <sup>https://github.com/rust-lang/rust/issues/57819</sup>: parser 1.138
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-54348.rs <sup>https://github.com/rust-lang/rust/issues/54348</sup>: consts 1.155
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-14309.rs <sup>https://github.com/rust-lang/rust/issues/14309</sup>: lint 1.160
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-4446.rs <sup>https://github.com/rust-lang/rust/issues/4446</sup>: threads-sendsync 1.203
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-53675-a-test-called-panic.rs <sup>https://github.com/rust-lang/rust/issues/53675</sup>: test-attrs 1.211
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-40231-2.rs <sup>https://github.com/rust-lang/rust/issues/40231</sup>: consts 1.213
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-22037.rs <sup>https://github.com/rust-lang/rust/issues/22037</sup>: associated-types 1.214
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-59029-2.rs <sup>https://github.com/rust-lang/rust/issues/59029</sup>: traits 1.219
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-18425.rs <sup>https://github.com/rust-lang/rust/issues/18425</sup>: consts 1.237
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-6157.rs <sup>https://github.com/rust-lang/rust/issues/6157</sup>: regions 1.238
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-33819.rs <sup>https://github.com/rust-lang/rust/issues/33819</sup>: borrowck 1.280
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-3683.rs <sup>https://github.com/rust-lang/rust/issues/3683</sup>: traits 1.283
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-8709.rs <sup>https://github.com/rust-lang/rust/issues/8709</sup>: macros 1.291
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-20616-9.rs <sup>https://github.com/rust-lang/rust/issues/20616</sup>: parser 1.293
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-64732.rs <sup>https://github.com/rust-lang/rust/issues/64732</sup>: parser 1.296
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-18655.rs <sup>https://github.com/rust-lang/rust/issues/18655</sup>: associated-types 1.305
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-32947.rs <sup>https://github.com/rust-lang/rust/issues/32947</sup>: simd 1.322
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-57198.rs <sup>https://github.com/rust-lang/rust/issues/57198</sup>: parser 1.342
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-10764-rpass.rs <sup>https://github.com/rust-lang/rust/issues/10764</sup>: extern 1.392
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-73541-2.rs <sup>https://github.com/rust-lang/rust/issues/73541</sup>: async-await 1.422
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-7970b.rs <sup>https://github.com/rust-lang/rust/issues/7970</sup>: parser 1.439
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-57684.rs <sup>https://github.com/rust-lang/rust/issues/57684</sup>: parser 1.512
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-33264.rs <sup>https://github.com/rust-lang/rust/issues/33264</sup>: llvm-asm 1.523
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-65284-suggest-generic-trait-bound.rs <sup>https://github.com/rust-lang/rust/issues/65284</sup>: suggestions 1.647
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-17458.rs <sup>https://github.com/rust-lang/rust/issues/17458</sup>: consts 1.711
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-56762.rs <sup>https://github.com/rust-lang/rust/issues/56762</sup>: consts 1.787
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-2216.rs <sup>https://github.com/rust-lang/rust/issues/2216</sup>: for-loop-while 1.856
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-45696-scribble-on-boxed-borrow.rs <sup>https://github.com/rust-lang/rust/issues/45696</sup>: nll 2.009
https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-46036.rs <sup>https://github.com/rust-lang/rust/issues/46036</sup>: nll 2.059

``@petrochenkov`` Can you put a place holder (like `N/A`) for tests without GitHub issues? It is a lot easier to parse fixed sized rows.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-borrow-checker Area: The borrow checker A-NLL Area: Non-lexical lifetimes (NLL) NLL-complete Working towards the "valid code works" goal
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants