Uh oh!
There was an error while loading. Please reload this page.
Return false from needs_drop for all zero-sized arrays. - #65389
Conversation
rust-highfive
commented
Oct 13, 2019
r? @davidtwco (rust_highfive has picked a reviewer for you, use r? to override) |
davidtwco
commented
Oct 13, 2019
r? @eddyb |
Centril
commented
Oct 13, 2019
We already special case zero sized arrays in other places so I'm comfortable with doing it here as well. However, cc @rust-lang/lang |
82e9edc to
c08a871CompareI added a regression test for the underlying const validation issue as well. A perf run might be informative here. This will result in more calls to |
Centril
commented
Oct 14, 2019
@bors try @rust-timer queue |
rust-timer
commented
Oct 14, 2019
Awaiting bors try build completion |
bors
commented
Oct 14, 2019
Return `false` from `needs_drop` for all zero-sized arrays. Resolves#65348. This changes the result of the `needs_drop` query from `true` to `false` for types such as `[Box<i32>; 0]`. I believe this change to be sound because a zero-sized array can never actually hold a value. This is an elegant way of resolving #65348 and #64945, but obviously it has much broader implications.
bors
commented
Oct 14, 2019
☀️ Try build successful - checks-azure |
rust-timer
commented
Oct 14, 2019
Queued e823bc1 with parent 36d4506, future comparison URL. |
rust-timer
commented
Oct 14, 2019
Finished benchmarking try commit e823bc1, comparison URL. |
Perf impact is negligible. Just needs an r+. |
eddyb
commented
Oct 15, 2019
@bors r+ |
bors
commented
Oct 15, 2019
📌 Commit c08a871 has been approved by |
…drop, r=eddyb Return `false` from `needs_drop` for all zero-sized arrays. Resolvesrust-lang#65348. This changes the result of the `needs_drop` query from `true` to `false` for types such as `[Box<i32>; 0]`. I believe this change to be sound because a zero-sized array can never actually hold a value. This is an elegant way of resolving rust-lang#65348 and rust-lang#64945, but obviously it has much broader implications.
…drop, r=eddyb Return `false` from `needs_drop` for all zero-sized arrays. Resolvesrust-lang#65348. This changes the result of the `needs_drop` query from `true` to `false` for types such as `[Box<i32>; 0]`. I believe this change to be sound because a zero-sized array can never actually hold a value. This is an elegant way of resolving rust-lang#65348 and rust-lang#64945, but obviously it has much broader implications.
…drop, r=eddyb Return `false` from `needs_drop` for all zero-sized arrays. Resolvesrust-lang#65348. This changes the result of the `needs_drop` query from `true` to `false` for types such as `[Box<i32>; 0]`. I believe this change to be sound because a zero-sized array can never actually hold a value. This is an elegant way of resolving rust-lang#65348 and rust-lang#64945, but obviously it has much broader implications.
Rollup of 14 pull requests Successful merges: - #64603 (Reducing spurious unused lifetime warnings.) - #64623 (Remove last uses of gensyms) - #65235 (don't assume we can *always* find a return type hint in async fn) - #65242 (Fix suggestion to constrain trait for method to be found) - #65265 (Cleanup librustc mir err codes) - #65293 (Optimize `try_expand_impl_trait_type`) - #65307 (Try fix incorrect "explicit lifetime name needed") - #65308 (Add long error explanation for E0574) - #65353 (save-analysis: Don't ICE when resolving qualified type paths in struct members) - #65389 (Return `false` from `needs_drop` for all zero-sized arrays.) - #65402 (Add troubleshooting section to PGO chapter in rustc book.) - #65425 (Optimize `BitIter`) - #65438 (Organize `never_type` tests) - #65444 (Implement AsRef<[T]> for List<T>) Failed merges: - #65390 (Add long error explanation for E0576) r? @ghost
bors
commented
Oct 16, 2019
☔ The latest upstream changes (presumably #65454) made this pull request unmergeable. Please resolve the merge conflicts. |
Resolves#65348.
This changes the result of the
needs_dropquery fromtruetofalsefor types such as[Box<i32>; 0]. I believe this change to be sound because a zero-sized array can never actually hold a value. This is an elegant way of resolving #65348 and #64945, but obviously it has much broader implications.