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

Drop partially bound function parameters in the expected order #56044

Open
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
@matthewjasper
Contributor

matthewjasper commented Nov 18, 2018

Given the function

fn foo((_x, _): (LogDrop, LogDrop), (_, _y): (LogDrop, LogDrop)) {}

Prior to 1.12.0 we dropped both _x and _y before the rest of their
respective parameters, since then we dropped _x and _y after. The
original order appears to be the correct order, as the value created
later is dropped first, so we revert to that order and add a test for
it.

While this is technically a breaking change, I can't work out how
anyone could be relying on this without making their code very
brittle. If this is considered to be too likely to break real world code
then I can revert the change and change the test to check for the
current order.

@rust-highfive

This comment has been minimized.

Collaborator

rust-highfive commented Nov 18, 2018

r? @cramertj

(rust_highfive has picked a reviewer for you, use r? to override)

@Mark-Simulacrum

This comment has been minimized.

Member

Mark-Simulacrum commented Nov 18, 2018

Given fn foo((_x, _): (LogDrop, LogDrop), (_, _y): (LogDrop, LogDrop)) {} I would expect the drop order to be arg1.1, arg2.0, _y, and _x because the _ arguments should be dropped immediately and then the other arguments are dropped in reverse order of declaration per http://rust-lang.github.io/rfcs/1857-stabilize-drop-order.html.

@matthewjasper

This comment has been minimized.

Contributor

matthewjasper commented Nov 18, 2018

Things bound to _ in arguments have never been dropped immediately (it's wrong for patterns using ref).

@RalfJung

This comment has been minimized.

Member

RalfJung commented Nov 24, 2018

I would have expected fn foo(PAT: T) { ... } to be the same as fn foo(_tmp: T) { let PAT = _tmp; ... }. So I agree with @Mark-Simulacrum, dropping immediately would be most intuitive, and everything else seems like an odd exception.

@cramertj

This comment has been minimized.

Member

cramertj commented Nov 26, 2018

@bors r+

@bors

This comment has been minimized.

Contributor

bors commented Nov 26, 2018

📌 Commit 7dc0dd2 has been approved by cramertj

@bors

This comment has been minimized.

Contributor

bors commented Nov 27, 2018

⌛️ Testing commit 7dc0dd2 with merge ee2f6f9...

bors added a commit that referenced this pull request Nov 27, 2018

Auto merge of #56044 - matthewjasper:function-param-drop-order, r=cra…
…mertj

Drop partially bound function parameters in the expected order

Given the function

```rust
fn foo((_x, _): (LogDrop, LogDrop), (_, _y): (LogDrop, LogDrop)) {}
```

Prior to 1.12.0 we dropped both `_x` and `_y` before the rest of their
respective parameters, since then we dropped `_x` and `_y` after. The
original order appears to be the correct order, as the value created
later is dropped first, so we revert to that order and add a test for
it.

While this is technically a breaking change, I can't work out how
anyone could be relying on this without making their code very
brittle. If this is considered to be too likely to break real world code
then I can revert the change and change the test to check for the
current order.
@bors

This comment has been minimized.

Contributor

bors commented Nov 27, 2018

💔 Test failed - status-travis

@rust-highfive

This comment has been minimized.

Collaborator

rust-highfive commented Nov 27, 2018

The job wasm32-unknown of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
[01:05:17] 
[01:05:17] thread 'main' panicked at 'Some tests failed', src/tools/compiletest/src/main.rs:503:22
[01:05:17] error: test run failed!
[01:05:17] status: exit code: 101
[01:05:17] command: "/node-v9.2.0-linux-x64/bin/node" "/checkout/src/etc/wasm32-shim.js" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass/binding/fn-arg-incomplete-pattern-drop-order/a.wasm"
[01:05:17] ------------------------------------------
[01:05:17] 
[01:05:17] ------------------------------------------
[01:05:17] stderr:
[01:05:17] stderr:
[01:05:17] ------------------------------------------
[01:05:17] RuntimeError: unreachable
[01:05:17]     at __rust_start_panic (wasm-function[82]:1)
[01:05:17]     at rust_panic (wasm-function[78]:39)
[01:05:17]     at _ZN3std9panicking20rust_panic_with_hook17hefa20f9e2d7144fcE (wasm-function[73]:346)
[01:05:17]     at _ZN3std9panicking11begin_panic17ha07741734e150442E (wasm-function[11]:49)
[01:05:17]     at _ZN36fn_arg_incomplete_pattern_drop_order3foo17hb9cbcbcdc62d43caE (wasm-function[2]:607)
[01:05:17]     at _ZN3std9panicking3try7do_call17hbbbd02620233e1d7E.llvm.12228513419448781796 (wasm-function[12]:348)
[01:05:17]     at __rust_maybe_catch_panic (wasm-function[81]:5)
[01:05:17]     at _ZN36fn_arg_incomplete_pattern_drop_order4main17h78f606c69bb2c1c8E (wasm-function[3]:295)
[01:05:17]     at _ZN3std2rt10lang_start28_$u7b$$u7b$closure$u7d$$u7d$17h898ef31c452dd768E (wasm-function[6]:25)
[01:05:17]     at _ZN3std10sys_common9backtrace28__rust_begin_short_backtrace17hd27616b21d0538aaE (wasm-function[62]:8)
[01:05:17]     at _ZN3std9panicking3try7do_call17hfb625b14a19c314fE (wasm-function[70]:20)
[01:05:17]     at __rust_maybe_catch_panic (wasm-function[81]:5)
[01:05:17]     at _ZN3std2rt19lang_start_internal17h89e1dbf50853ba79E (wasm-function[79]:270)
[01:05:17]     at _ZN3std2rt10lang_start17hbfa996f5e8ab0c4dE (wasm-function[5]:42)
[01:05:17]     at main (wasm-function[4]:11)
[01:05:17]     at Object.<anonymous> (/checkout/src/etc/wasm32-shim.js:136:20)
[01:05:17]     at Module._compile (module.js:641:30)
[01:05:17]     at Object.Module._extensions..js (module.js:652:10)
[01:05:17]     at Module.load (module.js:560:32)
[01:05:17]     at tryModuleLoad (module.js:503:12)
[01:05:17] ------------------------------------------
[01:05:17] 
[01:05:17] thread '[run-pass] run-pass/binding/fn-arg-incomplete-pattern-drop-order.rs' panicked at 'explicit panic', src/tools/compiletest/src/runtest.rs:3282:9
[01:05:17] note: Run with `RUST_BACKTRACE=1` for a backtrace.
---
[01:05:17] test result: FAILED. 2636 passed; 1 failed; 251 ignored; 0 measured; 0 filtered out
[01:05:17] 
[01:05:17] 
[01:05:17] 
[01:05:17] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" "--compile-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib" "--run-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/wasm32-unknown-unknown/lib" "--rustc-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--src-base" "/checkout/src/test/run-pass" "--build-base" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass" "--stage-id" "stage2-wasm32-unknown-unknown" "--mode" "run-pass" "--target" "wasm32-unknown-unknown" "--host" "x86_64-unknown-linux-gnu" "--llvm-filecheck" "/checkout/obj/build/x86_64-unknown-linux-gnu/llvm/build/bin/FileCheck" "--nodejs" "/node-v9.2.0-linux-x64/bin/node" "--host-rustcflags" "-Crpath -O -Zunstable-options " "--target-rustcflags" "-Crpath -O -Zunstable-options  -Lnative=/checkout/obj/build/wasm32-unknown-unknown/native/rust-test-helpers" "--docck-python" "/usr/bin/python2.7" "--lldb-python" "/usr/bin/python2.7" "--gdb" "/usr/bin/gdb" "--llvm-version" "8.0.0svn\n" "--cc" "" "--cxx" "" "--cflags" "" "--llvm-components" "" "--llvm-cxxflags" "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" "--android-cross-path" "" "--color" "always"
[01:05:17] 
[01:05:17] 
[01:05:17] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test --target wasm32-unknown-unknown src/test/run-make src/test/ui src/test/run-pass src/test/compile-fail src/test/mir-opt src/test/codegen-units src/libcore
[01:05:17] Build completed unsuccessfully in 1:02:53
---
travis_time:end:0b8a2e24:start=1543304505070614849,finish=1543304505077540370,duration=6925521
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:02cf9286
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:07de15a9
travis_time:start:07de15a9
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:258e1492
$ dmesg | grep -i kill

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 @TimNN. (Feature Requests)

pietroalbini added a commit to pietroalbini/rust that referenced this pull request Nov 28, 2018

Rollup merge of rust-lang#56044 - matthewjasper:function-param-drop-o…
…rder, r=cramertj

Drop partially bound function parameters in the expected order

Given the function

```rust
fn foo((_x, _): (LogDrop, LogDrop), (_, _y): (LogDrop, LogDrop)) {}
```

Prior to 1.12.0 we dropped both `_x` and `_y` before the rest of their
respective parameters, since then we dropped `_x` and `_y` after. The
original order appears to be the correct order, as the value created
later is dropped first, so we revert to that order and add a test for
it.

While this is technically a breaking change, I can't work out how
anyone could be relying on this without making their code very
brittle. If this is considered to be too likely to break real world code
then I can revert the change and change the test to check for the
current order.

bors added a commit that referenced this pull request Nov 28, 2018

Auto merge of #56325 - pietroalbini:rollup, r=pietroalbini
Rollup of 29 pull requests

Successful merges:

 - #55391 (bootstrap: clean up a few clippy findings)
 - #55821 (Use sort_by_cached_key when the key function is not trivial/free)
 - #56014 (add test for issue #21335)
 - #56021 (avoid features_untracked)
 - #56023 (atomic::Ordering: Get rid of misleading parts of intro)
 - #56044 (Drop partially bound function parameters in the expected order)
 - #56080 (Reduce the amount of bold text at doc.rlo)
 - #56090 (Overhaul `FileSearch` and `SearchPaths`)
 - #56114 (Enclose type in backticks for "non-exhaustive patterns" error)
 - #56124 (Fix small doc mistake on std::io::read::read_to_end)
 - #56127 (Update an outdated comment in mir building)
 - #56131 (Assorted tweaks)
 - #56148 (Add rustc-guide as a submodule)
 - #56149 (Make std::os::unix/linux::fs::MetadataExt::a/m/ctime* documentation clearer)
 - #56165 (drop glue takes in mutable references, it should reflect that in its type)
 - #56205 (Fix ICE with feature self_struct_ctor)
 - #56216 (Add TryFrom<&[T]> for [T; $N] where T: Copy)
 - #56220 (Suggest appropriate place for lifetime when declared after type arguments)
 - #56223 (Make JSON output from -Zprofile-json valid)
 - #56236 (Remove unsafe `unsafe` inner function.)
 - #56245 (Stabilize feature `macro_at_most_once_rep`)
 - #56255 (Update outdated code comments in StringReader)
 - #56257 (rustc-guide has moved to rust-lang/)
 - #56268 (Reuse the `P` in `InvocationCollector::fold_{,opt_}expr`.)
 - #56273 (Add missing doc link)
 - #56285 (move stage0.txt to toplevel directory)
 - #56289 (Fix small typo in comment of thread::stack_size)
 - #56294 (Fix a typo in the documentation of std::ffi)
 - #56300 (Fix alignment of stores to scalar pair)

Failed merges:

r? @ghost
@pnkfelix

This comment has been minimized.

Member

pnkfelix commented Nov 29, 2018

I find the uses of the word "immediately" confusing in the comments above by @Mark-Simulacrum and @RalfJung

Can we clarify if that is supposed to mean "immediately" at the end of the execution of foo? or immediately at the start of foo? Better still, maybe just write a example where foo itself prints a message to make the order absolultely concrete?

@RalfJung

This comment has been minimized.

Member

RalfJung commented Nov 29, 2018

@pnkfelix I stated my expected semantics as an equivalence with let bindings, as I care more about consistency of drop order than about when things are dropped. These two functions should do exactly the same (assuming ... does not refer to _tmp):

fn foo(PAT: T) { ... }
fn foo(_tmp: T) { let PAT = _tmp; ... }

I think this means they should be dropped at the beginning of foo? I must also be missing something else, or this is a native speaker thing, because I cannot imagine an interpretation of "immediate" that's not "dropped immediately", i.e., as soon as possible, i.e., when the function starts. What is "immediate" about dropping them at the end?

@Mark-Simulacrum

This comment has been minimized.

Member

Mark-Simulacrum commented Nov 29, 2018

I would expect this:

fn foo((_x, _): (LogDrop, LogDrop), (_, _y): (LogDrop, LogDrop)) {
// for naming:
// fn foo((a, b): (LogDrop, LogDrop), (c, d): (LogDrop, LogDrop)) {
// variables dropped "immediately," before function runs;
// technically I think c should drop first to preserve "reverse of declaration order"
// c dropped
// b dropped
// function runs
// variables dropped in reverse of declaration order:
// d dropped
// a dropped
}
@matthewjasper

This comment has been minimized.

Contributor

matthewjasper commented Nov 29, 2018

fn foo(PAT: T) { ... }
fn foo(_tmp: T) { let PAT = _tmp; ... }

These currently have different drop order: playground. This PR makes them have the same drop order.

@Centril Centril removed the I-nominated label Nov 29, 2018

}
}
fn foo((_x, _): (LogDrop, LogDrop), (_, _y): (LogDrop, LogDrop)) {}

This comment has been minimized.

@scottmcm

scottmcm Nov 29, 2018

Member

Could this test also have the let version, to explicitly demonstrate that they do the same thing?

Like

fn foo2(_temp1: (LogDrop, LogDrop), _temp2: (LogDrop, LogDrop)) {
    let (_x, _) = _temp1;
    let (_, _y) = _temp2;
}
@joshtriplett

This comment has been minimized.

Member

joshtriplett commented Nov 29, 2018

Consensus in the lang team meeting was that patterns in the function arguments should work exactly like the equivalent let bindings at the top of the function, in terms of drop order. So, fn foo((_x, _): (LogDrop, LogDrop), (_, _y): (LogDrop, LogDrop)) {} should drop in the same order and at the same time as:

fn foo(a: (LogDrop, LogDrop), b: (LogDrop, LogDrop)) {
    let (_x, _) = a;
    let (_, _y) = b;
    // ...
}
@nikomatsakis

This comment has been minimized.

Contributor

nikomatsakis commented Nov 29, 2018

As ever, I'm a bit nervous about changing existing behavior, particularly in an untestable way, though I also do agree with the desugaring shown above.

I would however like to know why this behavior changed in 1.12.0.

I'm also wondering if there is some special case for fn foo(a: u32) -- I feel like we did this at some point so as not to create as many MIR variables -- but having that affect drop order seems unfortunate.

@nikomatsakis nikomatsakis self-requested a review Nov 29, 2018

@matthewjasper

This comment has been minimized.

Contributor

matthewjasper commented Nov 29, 2018

I would however like to know why this behavior changed in 1.12.0.

Most likely it's due to MIR (and lack of tests for this).

I'm also wondering if there is some special case for fn foo(a: u32) -- I feel like we did this at some point so as not to create as many MIR variables -- but having that affect drop order seems unfortunate.

Yes. [mut] a: T only generates 1 variable, while (a,): (T,) generates 2.

@matthewjasper

This comment has been minimized.

Contributor

matthewjasper commented Nov 29, 2018

fn foo(a: (LogDrop, LogDrop), b: (LogDrop, LogDrop)) {
    let (_x, _) = a;
    let (_, _y) = b;
    // ...
}

This is possible, but would be even more of a change.

@matthewjasper matthewjasper force-pushed the matthewjasper:function-param-drop-order branch from 7dc0dd2 to 5459338 Nov 29, 2018

@matthewjasper

This comment has been minimized.

Contributor

matthewjasper commented Nov 29, 2018

I've expanded the test, but not changed the drop order yet (from the order this PR opened with). Once everyone has agreed an order then I'll update the PR again if needed.

@rust-highfive

This comment was marked as outdated.

Collaborator

rust-highfive commented Nov 29, 2018

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
travis_time:end:07ae0df2:start=1543526701828317527,finish=1543526704093468268,duration=2265150741
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#Pull-Requests-and-Security-Restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
Setting environment variables from .travis.yml
$ export IMAGE=x86_64-gnu-llvm-5.0
---
[00:48:23] .................................................................................................... 100/5065
[00:48:25] .................................................................................................... 200/5065
[00:48:28] .............................ii............................................ii...................ii.. 300/5065
[00:48:31] ..............................................................................................iii... 400/5065
[00:48:33] .....iiiiiiii.iii............................iii...........................................i........ 500/5065
[00:48:40] .................................................................................................... 700/5065
[00:48:45] ................................................................................................i... 800/5065
[00:48:49] ........i........................................................................................... 900/5065
[00:48:52] ...............iiiii..................ii.iiii....................................................... 1000/5065
---
[00:49:29] .................................................................................................... 2300/5065
[00:49:33] .................................................................................................... 2400/5065
[00:49:37] .................................................................................................... 2500/5065
[00:49:41] .................................................................................................... 2600/5065
[00:49:44] ........iiiiiiiii................................................................................... 2700/5065
[00:49:50] .................................................................................................... 2900/5065
[00:49:53] .................................................................................................... 3000/5065
[00:49:56] ......................................................................i............................. 3100/5065
[00:49:59] .................................................................................................... 3200/5065
---
[00:50:52] 
[00:50:52] running 2888 tests
[00:51:03] .................................................................................................... 100/2888
[00:51:13] .................................................................................i.................. 200/2888
[00:51:21] ........F........................................................................................... 300/2888
[00:51:39] .................................................................................................... 500/2888
[00:51:51] .................................................................................................... 600/2888
[00:52:05] .................................................................................................... 700/2888
[00:52:15] .................................................................................................... 800/2888
---
[00:56:47] failures:
[00:56:47] 
[00:56:47] ---- [run-pass] run-pass/binding/fn-arg-incomplete-pattern-drop-order.rs stdout ----
[00:56:47] 
[00:56:47] error: test compilation failed although it shouldn't!
[00:56:47] status: exit code: 1
[00:56:47] command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/src/test/run-pass/binding/fn-arg-incomplete-pattern-drop-order.rs" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-Zui-testing" "-C" "prefer-dynamic" "-o" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass/binding/fn-arg-incomplete-pattern-drop-order/a" "-Crpath" "-O" "-Zunstable-options" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass/binding/fn-arg-incomplete-pattern-drop-order/auxiliary"
[00:56:47] ------------------------------------------
[00:56:47] 
[00:56:47] ------------------------------------------
[00:56:47] stderr:
[00:56:47] stderr:
[00:56:47] ------------------------------------------
[00:56:47] {"message":"this function takes 1 parameter but 2 parameters were supplied","code":{"code":"E0061","explanation":"\nThe number of arguments passed to a function must match the number of arguments\nspecified in the function signature.\n\nFor example, a function like:\n\n```\nfn f(a: u16, b: &str) {}\n```\n\nMust always be called with exactly two arguments, e.g. `f(2, \"test\")`.\n\nNote that Rust does not have a notion of optional function arguments or\nvariadic functions (except for its C-FFI).\n"},"level":"error","spans":[{"file_name":"/checkout/src/test/run-pass/binding/fn-arg-incomplete-pattern-drop-order.rs","byte_start":1812,"byte_end":1820,"line_start":66,"line_end":66,"column_start":13,"column_end":21,"is_primary":true,"text":[{"text":"    (0..=4).for_each(test_drop_order, bindings_in_params);","highlight_start":13,"highlight_end":21}],"label":"expected 1 parameter","suggested_replacement":null,"suggestion_applicability":null,"expansion":null}],"children":[],"rendered":"error[E0061]: this function takes 1 parameter but 2 parameters were supplied\n  --> /checkout/src/test/run-pass/binding/fn-arg-incomplete-pattern-drop-order.rs:66:13\n   |\nLL |     (0..=4).for_each(test_drop_order, bindings_in_params);\n   |             ^^^^^^^^ expected 1 parameter\n\n"}
[00:56:47] {"message":"this function takes 1 parameter but 2 parameters were supplied","code":{"code":"E0061","explanation":"\nThe number of arguments passed to a function must match the number of arguments\nspecified in the function signature.\n\nFor example, a function like:\n\n```\nfn f(a: u16, b: &str) {}\n```\n\nMust always be called with exactly two arguments, e.g. `f(2, \"test\")`.\n\nNote that Rust does not have a notion of optional function arguments or\nvariadic functions (except for its C-FFI).\n"},"level":"error","spans":[{"file_name":"/checkout/src/test/run-pass/binding/fn-arg-incomplete-pattern-drop-order.rs","byte_start":1871,"byte_end":1879,"line_start":67,"line_end":67,"column_start":13,"column_end":21,"is_primary":true,"text":[{"text":"    (0..=4).for_each(test_drop_order, bindings_with_let);","highlight_start":13,"highlight_end":21}],"label":"expected 1 parameter","suggested_replacement":null,"suggestion_applicability":null,"expansion":null}],"children":[],"rendered":"error[E0061]: this function takes 1 parameter but 2 parameters were supplied\n  --> /checkout/src/test/run-pass/binding/fn-arg-incomplete-pattern-drop-order.rs:67:13\n   |\nLL |     (0..=4).for_each(test_drop_order, bindings_with_let);\n   |             ^^^^^^^^ expected 1 parameter\n\n"}
[00:56:47] {"message":"this function takes 1 parameter but 2 parameters were supplied","code":{"code":"E0061","explanation":"\nThe number of arguments passed to a function must match the number of arguments\nspecified in the function signature.\n\nFor example, a function like:\n\n```\nfn f(a: u16, b: &str) {}\n```\n\nMust always be called with exactly two arguments, e.g. `f(2, \"test\")`.\n\nNote that Rust does not have a notion of optional function arguments or\nvariadic functions (except for its C-FFI).\n"},"level":"error","spans":[{"file_name":"/checkout/src/test/run-pass/binding/fn-arg-incomplete-pattern-drop-order.rs","byte_start":1929,"byte_end":1937,"line_start":68,"line_end":68,"column_start":13,"column_end":21,"is_primary":true,"text":[{"text":"    (0..=4).for_each(test_drop_order, bindings_in_closure);","highlight_start":13,"highlight_end":21}],"label":"expected 1 parameter","suggested_replacement":null,"suggestion_applicability":null,"expansion":null}],"children":[],"rendered":"error[E0061]: this function takes 1 parameter but 2 parameters were supplied\n  --> /checkout/src/test/run-pass/binding/fn-arg-incomplete-pattern-drop-order.rs:68:13\n   |\nLL |     (0..=4).for_each(test_drop_order, bindings_in_closure);\n   |             ^^^^^^^^ expected 1 parameter\n\n"}
[00:56:47] {"message":"aborting due to 3 previous errors","code":null,"level":"error","spans":[],"children":[],"rendered":"error: aborting due to 3 previous errors\n\n"}
[00:56:47] {"message":"For more information about this error, try `rustc --explain E0061`.","code":null,"level":"","spans":[],"children":[],"rendered":"For more information about this error, try `rustc --explain E0061`.\n"}
[00:56:47] ------------------------------------------
[00:56:47] 
[00:56:47] thread '[run-pass] run-pass/binding/fn-arg-incomplete-pattern-drop-order.rs' panicked at 'explicit panic', src/tools/compiletest/src/runtest.rs:3282:9
[00:56:47] note: Run with `RUST_BACKTRACE=1` for a backtrace.
---
[00:56:47] 
[00:56:47] thread 'main' panicked at 'Some tests failed', src/tools/compiletest/src/main.rs:503:22
[00:56:47] 
[00:56:47] 
[00:56:47] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" "--compile-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib" "--run-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "--rustc-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--src-base" "/checkout/src/test/run-pass" "--build-base" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass" "--stage-id" "stage2-x86_64-unknown-linux-gnu" "--mode" "run-pass" "--target" "x86_64-unknown-linux-gnu" "--host" "x86_64-unknown-linux-gnu" "--llvm-filecheck" "/usr/lib/llvm-5.0/bin/FileCheck" "--host-rustcflags" "-Crpath -O -Zunstable-options " "--target-rustcflags" "-Crpath -O -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--docck-python" "/usr/bin/python2.7" "--lldb-python" "/usr/bin/python2.7" "--gdb" "/usr/bin/gdb" "--quiet" "--llvm-version" "5.0.0\n" "--system-llvm" "--cc" "" "--cxx" "" "--cflags" "" "--llvm-components" "" "--llvm-cxxflags" "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" "--android-cross-path" "" "--color" "always"
[00:56:47] 
[00:56:47] 
[00:56:47] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test
[00:56:47] Build completed unsuccessfully in 0:12:10
[00:56:47] Build completed unsuccessfully in 0:12:10
[00:56:47] Makefile:58: recipe for target 'check' failed
[00:56:47] make: *** [check] Error 1
The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:2534ae80
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
Thu Nov 29 22:22:01 UTC 2018
---
travis_time:end:10365f2e:start=1543530123096078110,finish=1543530123156577087,duration=60498977
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:1003a5ac
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:255ab500
$ dmesg | grep -i kill

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 @TimNN. (Feature Requests)

Drop function parameters in expected order
Given the function

fn foo((_x, _): (LogDrop, LogDrop), (_, _y): (LogDrop, LogDrop)) {}

Prior to 1.12 we dropped both `_x` and `_y` before the rest of their
respective parameters, since then we dropped `_x` and `_y` after. The
original order appears to be the correct order, as the value created
later is dropped first, so we revert to that order and add a test for
it.

@matthewjasper matthewjasper force-pushed the matthewjasper:function-param-drop-order branch from 5459338 to 914515f Nov 30, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment