-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Comments
I think we have to decide how we are going to handle 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. |
An alternative of course is to restore the "full knowledge" to |
I would prefer to have "full |
@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? |
I think MIR borrowck currently has an even stupider version of the Box borrow rules, which needs to be removed. |
I'm going to try writing out some tests here in the comments and their current behavior. Access field 1 while field 0 is borrowedfn 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
This gives an error in both AST / MIR, as expected. Access field 1 when field 0 is borrowed
This gives an error only in AST, as expected. Return reborrowed mutable ref in field 0
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.) |
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 |
It is. However, luckily for us, |
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).
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
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() {} |
This is just nikomatsakis/nll-rfc#40, or on the AST side #31567. |
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?) |
I'm going to try to look at this today |
I think I have a specialized fix specific to It is this commit: pnkfelix@596f363 I hope to put up a PR tomorrow. |
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 |
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 |
but oops I really need to get better at testing stuff first. Sigh. |
(okay now PR #52782 is a change I'm pretty confident in. And as a bonus it also passes the test suite.) |
…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.
…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.
…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.
see also some follow-up discussion here #43234 (comment) |
…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.
…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.
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:AST borrowck reports an error on both lines, but MIR borrowck lets the code pass:
This should be investigated and solved
The text was updated successfully, but these errors were encountered: