Uh oh!
There was an error while loading. Please reload this page.
tests encoding current behavior for various cases of "binding" to _. - #69573
Conversation
rust-highfive
commented
Feb 29, 2020
(rust_highfive has picked a reviewer for you, use r? to override) |
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
General note: Would be good to also test if let as it might diverge somewhat in the future in terms of MIR building.
There was a problem hiding this comment.
hmm. interesting the most obvious "ports" of these tests as written into if let form runs afoul of "warning: irrefutable if-let pattern"
Which makes total sense.
But also leads me to wonder whether I should be testing them in different fashion. I'm not sure these tests translate over to refutable patterns, because if the data has been moved away, then you won't have a discriminant to inspect.
There was a problem hiding this comment.
Perhaps just inserting an Option<_> layer would be good for the match/if-let tests? iirc I did that in a somewhat similar test somewhere. Presumably _ should work below sum types as well.
Uh oh!
There was an error while loading. Please reload this page.
Centril
commented
Mar 1, 2020
r? @Centril r=me with comments ^-- addressed. |
rust-highfive
commented
Mar 5, 2020
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
pnkfelix
commented
Mar 6, 2020
whoops! (wasn't able to test locally because I had to task switch to resolving a beta regression. I'll fix the tests.) |
Dylan-DPC-zz
commented
Apr 2, 2020
@pnkfelix any updates? |
The `_` binding form is special, in that it encodes a "no-op": nothing is actually bound, and thus nothing is moved or borrowed in this scenario. Usually we do the "right" thing in all such cases. The exceptions are explicitly pointed out in this test case, so that we keep track of whether they are eventually fixed.
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
327a869 to
22ea3a4CompareCentril
commented
Apr 10, 2020
Decided to @bors r+ |
bors
commented
Apr 10, 2020
📌 Commit 22ea3a4 has been approved by |
…entril tests encoding current behavior for various cases of "binding" to _. The `_` binding form is special, in that it encodes a "no-op": nothing is actually bound, and thus nothing is moved or borrowed in this scenario. Usually we do the "right" thing in all such cases. The exceptions are explicitly pointed out in this test case, so that we keep track of whether they are eventually fixed. Cc rust-lang#53114. (This does not close the aforementioned issue; it just adds the tests encoding the current behavior, which we hope to eventually fix.)
…entril tests encoding current behavior for various cases of "binding" to _. The `_` binding form is special, in that it encodes a "no-op": nothing is actually bound, and thus nothing is moved or borrowed in this scenario. Usually we do the "right" thing in all such cases. The exceptions are explicitly pointed out in this test case, so that we keep track of whether they are eventually fixed. Cc rust-lang#53114. (This does not close the aforementioned issue; it just adds the tests encoding the current behavior, which we hope to eventually fix.)
bors
commented
Apr 11, 2020
bors
commented
Apr 11, 2020
☀️ Test successful - checks-azure |
Rollup of 5 pull requests Successful merges: - rust-lang#69573 (tests encoding current behavior for various cases of "binding" to _.) - rust-lang#70881 (bootstrap: work around "unused attribute" errors in incremental stdlib rebuilds.) - rust-lang#70957 (Normalize MIR locals' types for generator layout computation.) - rust-lang#70962 (added machine hooks to track deallocations) - rust-lang#70982 (Normalize function signature in function casting check procedure) Failed merges: r? @ghost
The
_binding form is special, in that it encodes a "no-op": nothing is actually bound, and thus nothing is moved or borrowed in this scenario. Usually we do the "right" thing in all such cases. The exceptions are explicitly pointed out in this test case, so that we keep track of whether they are eventually fixed.Cc #53114.
(This does not close the aforementioned issue; it just adds the tests encoding the current behavior, which we hope to eventually fix.)