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

Make the semantics of Vec::truncate(N) consistent with slices. #64432

Merged
merged 1 commit into from Nov 15, 2019

Conversation

@gnzlbg
Copy link
Contributor

gnzlbg commented Sep 13, 2019

This commit simplifies the implementation of Vec::truncate(N) and
makes its semantics identical to dropping the [vec.len() - N..]
sub-slice tail of the vector, which is the same behavior as dropping a
vector containing the same sub-slice.

This changes two unspecified aspects of Vec::truncate behavior:

  • the drop order, from back-to-front to front-to-back,
  • the behavior of Vec::truncate on panics: if dropping one element of
    the tail panics, currently, Vec::truncate panics, but with this PR all other
    elements are still dropped, and if dropping a second element of the tail
    panics, with this PR, the program aborts.

Programs can trivially observe both changes. For example
(playground):

fn main() {
    struct Bomb(usize);
    impl Drop for Bomb {
        fn drop(&mut self) {
            panic!(format!("{}", self.0));
        }
    }
    let mut v = vec![Bomb(0), Bomb(1)];
    std::panic::catch_unwind(std::panic::AssertUnwindSafe(|| {
        v.truncate(0);
    }));
    assert_eq!(v.len(), 1);
    std::mem::forget(v);
}

panics printing 1 today and succeeds. With this change, it panics
printing 0 first (due to the drop order change), and then aborts
with a double-panic printing 1, just like dropping the
[Bomb(0), Bomb(1)] slice does, or dropping
vec![Bomb(0), Bomb(1)] does.

This needs to go through a crater run.

r? @SimonSapin

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Sep 14, 2019

☔️ The latest upstream changes (presumably #64456) made this pull request unmergeable. Please resolve the merge conflicts.

@scottmcm

This comment has been minimized.

Copy link
Member

scottmcm commented Sep 15, 2019

This changes the drop order from back-to-front to front-to-back, right? Is that something that'd be acceptable to change? My recollection of the field-drop-order discussion was that it was too scary to contemplate changing, so I'm not sure how here would be different.

(The abort-of-double-panic difference doesn't bother me.)

@gnzlbg gnzlbg force-pushed the gnzlbg:simplify_truncate branch from 12b8d2f to c326206 Sep 15, 2019
@gnzlbg

This comment has been minimized.

Copy link
Contributor Author

gnzlbg commented Sep 15, 2019

This changes the drop order from back-to-front to front-to-back, right?

Yes, exactly. I've updated the PR message to try to make things clearer. Could you let me know if it is better now ?

Also, could we schedule a try run? and if it passes, a crater run?

This would probably need to be FCP'ed by @rust-lang/libs .

This commit simplifies the implementation of `Vec::truncate(N)` and
makes its semantics identical to dropping the `[vec.len() - N..]`
sub-slice tail of the vector, which is the same behavior as dropping a
vector containing the same sub-slice.

This changes two unspecified aspects of `Vec::truncate` behavior:

* the drop order, from back-to-front to front-to-back,
* the behavior of `Vec::truncate` on panics: if dropping one element of
  the tail panics, currently, `Vec::truncate` panics, but with this PR all other
  elements are still dropped, and if dropping a second element of the tail
  panics, with this PR, the program aborts.

Programs can trivially observe both changes. For example
([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=7bef575b83b06e82b3e3529e4edbcac7)):

```rust
fn main() {
    struct Bomb(usize);
    impl Drop for Bomb {
        fn drop(&mut self) {
            panic!(format!("{}", self.0));
        }
    }
    let mut v = vec![Bomb(0), Bomb(1)];
    std::panic::catch_unwind(std::panic::AssertUnwindSafe(|| {
        v.truncate(0);
    }));
    assert_eq!(v.len(), 1);
    std::mem::forget(v);
}
```

panics printing `1` today and succeeds. With this change, it panics
printing `0` first (due to the drop order change), and then aborts
with a double-panic printing `1`, just like dropping the
`[Bomb(0), Bomb(1)]` slice does, or dropping
`vec![Bomb(0), Bomb(1)]` does.
@gnzlbg gnzlbg force-pushed the gnzlbg:simplify_truncate branch from c326206 to 6da4df9 Sep 15, 2019
@bluss

This comment has been minimized.

Copy link
Member

bluss commented Sep 15, 2019

Was there any particular use case or problem that made you want to change this?

@gnzlbg

This comment has been minimized.

Copy link
Contributor Author

gnzlbg commented Sep 15, 2019

Some arguments against doing #64375 were that it complicates the implementation of Vec::truncate. This was proposed there as a way to simplify the implementation while gaining all optimizations that drop_in_place magically does. It was decided that such change would be out-of-scope for that PR because of the potential change in semantics, and that whether it should or can be done should be explored after that PR was merged.

@gnzlbg

This comment has been minimized.

Copy link
Contributor Author

gnzlbg commented Sep 15, 2019

We are also documenting the semantics and guarantees about drop and panicking in the language reference (rust-lang/reference#348) which is what made me realize that the semantics of the drop glue that the compiler generates for aggregates like slices differs from the std::collections implements for some of their methods.

@kornelski

This comment has been minimized.

Copy link
Contributor

kornelski commented Sep 16, 2019

I think consistency is a good argument. It makes sense for vec.clear() and drop(vec) to behave the same.

@JohnCSimon

This comment has been minimized.

Copy link
Member

JohnCSimon commented Sep 28, 2019

Ping from triage
@scottmcm @kornelski @gnzlbg This has sat idle for a week.
Thanks!

@scottmcm

This comment has been minimized.

Copy link
Member

scottmcm commented Sep 28, 2019

Marking needs-fcp per #64432 (comment)

@alexcrichton

This comment has been minimized.

Copy link
Member

alexcrichton commented Sep 30, 2019

@rfcbot fcp merge

Thanks @gnzlbg for the clear writeup here, my only question is what we're making this consistent with which wasn't immediately clear after reading the PR description but @kornelski's comment above cleared that up for me.

@rfcbot

This comment has been minimized.

Copy link

rfcbot commented Sep 30, 2019

Team member @alexcrichton has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@Dylan-DPC

This comment has been minimized.

Copy link
Member

Dylan-DPC commented Oct 28, 2019

@Kimundi @SimonSapin @withoutboats waiting for your consensus on the above merge

@rfcbot

This comment has been minimized.

Copy link

rfcbot commented Oct 30, 2019

🔔 This is now entering its final comment period, as per the review above. 🔔

@alexcrichton

This comment has been minimized.

Copy link
Member

alexcrichton commented Nov 11, 2019

@bors: r+

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Nov 11, 2019

📌 Commit 6da4df9 has been approved by alexcrichton

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Nov 11, 2019

⌛️ Testing commit 6da4df9 with merge 97e4596...

bors added a commit that referenced this pull request Nov 11, 2019
Make the semantics of Vec::truncate(N) consistent with slices.

This commit simplifies the implementation of `Vec::truncate(N)` and
makes its semantics identical to dropping the `[vec.len() - N..]`
sub-slice tail of the vector, which is the same behavior as dropping a
vector containing the same sub-slice.

This changes two unspecified aspects of `Vec::truncate` behavior:

* the drop order, from back-to-front to front-to-back,
* the behavior of `Vec::truncate` on panics: if dropping one element of
  the tail panics, currently, `Vec::truncate` panics, but with this PR all other
  elements are still dropped, and if dropping a second element of the tail
  panics, with this PR, the program aborts.

Programs can trivially observe both changes. For example
([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=7bef575b83b06e82b3e3529e4edbcac7)):

```rust
fn main() {
    struct Bomb(usize);
    impl Drop for Bomb {
        fn drop(&mut self) {
            panic!(format!("{}", self.0));
        }
    }
    let mut v = vec![Bomb(0), Bomb(1)];
    std::panic::catch_unwind(std::panic::AssertUnwindSafe(|| {
        v.truncate(0);
    }));
    assert_eq!(v.len(), 1);
    std::mem::forget(v);
}
```

panics printing `1` today and succeeds. With this change, it panics
printing `0` first (due to the drop order change), and then aborts
with a double-panic printing `1`, just like dropping the
`[Bomb(0), Bomb(1)]` slice does, or dropping
`vec![Bomb(0), Bomb(1)]` does.

This needs to go through a crater run.

r? @SimonSapin
@rust-highfive

This comment has been minimized.

Copy link
Collaborator

rust-highfive commented Nov 11, 2019

The job dist-x86_64-mingw of your PR failed (pretty log, 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.
2019-11-11T17:11:57.1890390Z 
2019-11-11T17:11:57.1890444Z 
2019-11-11T17:11:57.1890500Z 
2019-11-11T17:11:57.1890531Z 
2019-11-11T17:11:57.1890645Z             panic!(format!("{}", self.0));
2019-11-11T17:11:57.1890723Z         fn drop(&mut self) {
2019-11-11T17:11:57.1890814Z         v.truncate(0);
2019-11-11T17:11:57.1891007Z     assert_eq!(v.len(), 1);
2019-11-11T17:11:57.1891007Z     assert_eq!(v.len(), 1);
2019-11-11T17:11:57.1891081Z     impl Drop for Bomb {
2019-11-11T17:11:57.1891185Z     let mut v = vec![Bomb(0), Bomb(1)];
2019-11-11T17:11:57.1891281Z     std::mem::forget(v);
2019-11-11T17:11:57.1891390Z     std::panic::catch_unwind(std::panic::AssertUnwindSafe(|| {
2019-11-11T17:11:57.1891482Z     struct Bomb(usize);
2019-11-11T17:11:57.1891641Z     }));
2019-11-11T17:11:57.1891641Z     }));
2019-11-11T17:11:57.1891718Z   elements are still dropped, and if dropping a second element of the tail
2019-11-11T17:11:57.1891818Z   panics, with this PR, the program aborts.
2019-11-11T17:11:57.1891907Z   the tail panics, currently, `Vec::truncate` panics, but with this PR all other
2019-11-11T17:11:57.1892037Z ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=7bef575b83b06e82b3e3529e4edbcac7)):
2019-11-11T17:11:57.1892162Z * the behavior of `Vec::truncate` on panics: if dropping one element of
2019-11-11T17:11:57.1892254Z * the drop order, from back-to-front to front-to-back,
2019-11-11T17:11:57.1892464Z AGENT_DISABLELOGPLUGIN_TESTFILEPUBLISHERPLUGIN=true
2019-11-11T17:11:57.1892567Z AGENT_DISABLELOGPLUGIN_TESTRESULTLOGPLUGIN=true
2019-11-11T17:11:57.1893239Z AGENT_HOMEDIRECTORY=C:\agents\2.160.0
2019-11-11T17:11:57.1893324Z AGENT_ID=511
---
2019-11-11T17:11:57.1903405Z MSDEPLOY_HTTP_USER_AGENT=VSTS_d439fc94-e01f-4249-b63e-d8392bc0247c_build_10_0
2019-11-11T17:11:57.1903508Z MSMPI_BIN=C:\Program Files\Microsoft MPI\Bin\
2019-11-11T17:11:57.1903577Z MSYSTEM=MINGW64
2019-11-11T17:11:57.1903656Z MSYS_BITS=64
2019-11-11T17:11:57.1903732Z Make the semantics of Vec::truncate(N) consistent with slices.
2019-11-11T17:11:57.1903968Z NPM_CONFIG_CACHE=C:\npm\cache
2019-11-11T17:11:57.1904037Z NPM_CONFIG_PREFIX=C:\npm\prefix
2019-11-11T17:11:57.1904117Z NUMBER_OF_PROCESSORS=2
2019-11-11T17:11:57.1904182Z OS=Windows_NT
---
2019-11-11T17:11:57.1907619Z PYTHON_HOME=C:/hostedtoolcache/windows\Python\3.6.8\x64
2019-11-11T17:11:57.1907710Z ProgramData=C:\ProgramData
2019-11-11T17:11:57.1907783Z ProgramFiles(x86)=C:\Program Files (x86)
2019-11-11T17:11:57.1907869Z ProgramW6432=C:\Program Files
2019-11-11T17:11:57.1907951Z Programs can trivially observe both changes. For example
2019-11-11T17:11:57.1908159Z RUST_CONFIGURE_ARGS=--build=x86_64-pc-windows-gnu --enable-full-tools --enable-profiler
2019-11-11T17:11:57.1908255Z SCCACHE_AWS_ACCESS_KEY_ID=AKIA46X5W6CZPECECL6V
2019-11-11T17:11:57.1908342Z SCCACHE_BUCKET=rust-lang-ci-sccache2
2019-11-11T17:11:57.1908411Z SCRIPT=python x.py dist
---
2019-11-11T17:11:57.1928398Z TMP=/tmp
2019-11-11T17:11:57.1928499Z TOOLSTATE_ISSUES_API_URL=https://api.github.com/repos/rust-lang/rust/issues
2019-11-11T17:11:57.1928638Z TOOLSTATE_PUBLISH=1
2019-11-11T17:11:57.1928741Z TOOLSTATE_REPO=https://github.com/rust-lang-nursery/rust-toolstate
2019-11-11T17:11:57.1928841Z This changes two unspecified aspects of `Vec::truncate` behavior:
2019-11-11T17:11:57.1928982Z This commit simplifies the implementation of `Vec::truncate(N)` and
2019-11-11T17:11:57.1929090Z This needs to go through a crater run.
2019-11-11T17:11:57.1929272Z USERDOMAIN=fv-az433
2019-11-11T17:11:57.1929340Z USERDOMAIN_ROAMINGPROFILE=fv-az433
2019-11-11T17:11:57.1929417Z USERNAME=VssAdministrator
2019-11-11T17:11:57.1929487Z USERPROFILE=C:\Users\VssAdministrator
2019-11-11T17:11:57.1929487Z USERPROFILE=C:\Users\VssAdministrator
2019-11-11T17:11:57.1929566Z VCPKG_INSTALLATION_ROOT=C:\vcpkg
2019-11-11T17:11:57.1929670Z VS140COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\
2019-11-11T17:11:57.1929764Z VSTS_AGENT_PERFLOG=c:\vsts\perflog
2019-11-11T17:11:57.1929856Z VSTS_PROCESS_LOOKUP_ID=vsts_8b8f5827-a95e-4f81-af4c-2d131204767c
2019-11-11T17:11:57.1929933Z WINDIR=C:\windows
2019-11-11T17:11:57.1930013Z WIX=C:\Program Files (x86)\WiX Toolset v3.11\
2019-11-11T17:11:57.1930084Z _=/usr/bin/printenv
2019-11-11T17:11:57.1930163Z `[Bomb(0), Bomb(1)]` slice does, or dropping
2019-11-11T17:11:57.1930296Z ```rust
2019-11-11T17:11:57.1930296Z ```rust
2019-11-11T17:11:57.1930360Z `vec![Bomb(0), Bomb(1)]` does.
2019-11-11T17:11:57.1930502Z fn main() {
2019-11-11T17:11:57.1930502Z fn main() {
2019-11-11T17:11:57.1930579Z makes its semantics identical to dropping the `[vec.len() - N..]`
2019-11-11T17:11:57.1930683Z panics printing `1` today and succeeds. With this change, it panics
2019-11-11T17:11:57.1930777Z printing `0` first (due to the drop order change), and then aborts
2019-11-11T17:11:57.1930956Z sub-slice tail of the vector, which is the same behavior as dropping a
2019-11-11T17:11:57.1931173Z vector containing the same sub-slice.
2019-11-11T17:11:57.1931173Z vector containing the same sub-slice.
2019-11-11T17:11:57.1931264Z with a double-panic printing `1`, just like dropping the
2019-11-11T17:11:57.1931417Z 
2019-11-11T17:11:57.1931477Z disk usage:
2019-11-11T17:11:57.2894098Z Filesystem            Size  Used Avail Use% Mounted on
2019-11-11T17:11:57.2894223Z C:/Program Files/Git  256G  140G  116G  55% /
---
2019-11-11T19:18:26.5253293Z [RUSTC-TIMING] vec_map test:false 0.304
2019-11-11T19:18:26.5309990Z    Compiling shell-escape v0.1.4
2019-11-11T19:18:27.4951357Z [RUSTC-TIMING] shell_escape test:false 0.941
2019-11-11T19:18:27.4999543Z    Compiling hex v0.4.0
2019-11-11T19:18:30.8159555Z memory allocation of 4294967304 bytes failed[RUSTC-TIMING] hex test:false 5.070
2019-11-11T19:18:30.8186277Z error: could not compile `hex`.
2019-11-11T19:18:30.8186665Z warning: build failed, waiting for other jobs to finish...
2019-11-11T19:18:30.8471437Z memory allocation of 536870920 bytes failed[RUSTC-TIMING] hex test:false 3.329
2019-11-11T19:18:30.8610886Z error: could not compile `hex`.
2019-11-11T19:18:30.8611578Z To learn more, run the command again with --verbose.
2019-11-11T19:18:30.8661589Z command did not execute successfully: "D:\\a\\1\\s\\build\\x86_64-pc-windows-gnu\\stage0\\bin\\cargo.exe" "build" "-Zconfig-profile" "--target" "x86_64-pc-windows-gnu" "-Zbinary-dep-depinfo" "-j" "2" "--release" "--locked" "--color" "always" "--manifest-path" "D:\\a\\1\\s\\src/tools/cargo\\Cargo.toml" "--features" "rustc-workspace-hack/all-static" "--message-format" "json-render-diagnostics"
2019-11-11T19:18:30.8661864Z expected success, got: exit code: 101
2019-11-11T19:18:30.9567202Z failed to run: D:\a\1\s\build\bootstrap\debug\bootstrap dist
2019-11-11T19:18:30.9567202Z failed to run: D:\a\1\s\build\bootstrap\debug\bootstrap dist
2019-11-11T19:18:30.9567624Z Build completed unsuccessfully in 1:56:38
2019-11-11T19:18:31.0064759Z == clock drift check ==
2019-11-11T19:18:31.1001283Z   local time: Mon Nov 11 19:18:31 CUT 2019
2019-11-11T19:18:31.7346402Z   network time: Mon, 11 Nov 2019 19:18:31 GMT
2019-11-11T19:18:31.7365326Z == end clock drift check ==
2019-11-11T19:18:31.8075886Z 
2019-11-11T19:18:32.1761195Z ##[error]Bash exited with code '1'.
2019-11-11T19:18:32.2460027Z ##[section]Starting: Checkout
2019-11-11T19:18:32.3121061Z ==============================================================================
2019-11-11T19:18:32.3121187Z Task         : Get sources
2019-11-11T19:18:32.3121333Z Description  : Get sources from a repository. Supports Git, TfsVC, and SVN repositories.

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)

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Nov 11, 2019

💔 Test failed - checks-azure

bors added a commit that referenced this pull request Nov 11, 2019
Use ptr::drop_in_place for VecDeque::truncate and VecDeque::clear

This commit allows `VecDeque::truncate` to take advantage of its (largely) contiguous memory layout and is consistent with the change in #64432 for `Vec`. As with the change to `Vec::truncate`, this changes both:

- the drop order, from back-to-front to front-to-back
- the behavior when dropping an element panics

For consistency, it also changes the behavior when dropping an element panics for `VecDeque::clear`.

These changes in behavior can be observed. This example ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=d0b1f2edc123437a2f704cbe8d93d828))
```rust
use std::collections::VecDeque;

fn main() {
    struct Bomb(usize);
    impl Drop for Bomb {
        fn drop(&mut self) {
            panic!(format!("{}", self.0));
        }
    }
    let mut v = VecDeque::from(vec![Bomb(0), Bomb(1)]);
    std::panic::catch_unwind(std::panic::AssertUnwindSafe(|| {
        v.truncate(0);
    }));
    std::mem::forget(v);
}
```
panics printing `1` today and succeeds. `v.clear()` panics printing `0` today and succeeds. With the change, `v.clear()`, `v.truncate(0)`, and dropping the `VecDeque` all panic printing `0` first and then abort with a double-panic printing `1`.

The motivation for this was making `VecDeque::truncate` more efficient since it was used in the implementation of `VecDeque::clone_from` (#65069), but it also makes behavior more consistent within the `VecDeque` and with `Vec` if that change is accepted (this probably doesn't make sense to merge if not).

This might need a crater run and an FCP as well.
@gnzlbg

This comment has been minimized.

Copy link
Contributor Author

gnzlbg commented Nov 13, 2019

Looks like we ran out of memory ?

@alexcrichton

This comment has been minimized.

Copy link
Member

alexcrichton commented Nov 13, 2019

@bors: retry

#66342

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Nov 13, 2019

⌛️ Testing commit 6da4df9 with merge d151166...

bors added a commit that referenced this pull request Nov 13, 2019
Make the semantics of Vec::truncate(N) consistent with slices.

This commit simplifies the implementation of `Vec::truncate(N)` and
makes its semantics identical to dropping the `[vec.len() - N..]`
sub-slice tail of the vector, which is the same behavior as dropping a
vector containing the same sub-slice.

This changes two unspecified aspects of `Vec::truncate` behavior:

* the drop order, from back-to-front to front-to-back,
* the behavior of `Vec::truncate` on panics: if dropping one element of
  the tail panics, currently, `Vec::truncate` panics, but with this PR all other
  elements are still dropped, and if dropping a second element of the tail
  panics, with this PR, the program aborts.

Programs can trivially observe both changes. For example
([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=7bef575b83b06e82b3e3529e4edbcac7)):

```rust
fn main() {
    struct Bomb(usize);
    impl Drop for Bomb {
        fn drop(&mut self) {
            panic!(format!("{}", self.0));
        }
    }
    let mut v = vec![Bomb(0), Bomb(1)];
    std::panic::catch_unwind(std::panic::AssertUnwindSafe(|| {
        v.truncate(0);
    }));
    assert_eq!(v.len(), 1);
    std::mem::forget(v);
}
```

panics printing `1` today and succeeds. With this change, it panics
printing `0` first (due to the drop order change), and then aborts
with a double-panic printing `1`, just like dropping the
`[Bomb(0), Bomb(1)]` slice does, or dropping
`vec![Bomb(0), Bomb(1)]` does.

This needs to go through a crater run.

r? @SimonSapin
@rust-highfive

This comment has been minimized.

Copy link
Collaborator

rust-highfive commented Nov 13, 2019

The job dist-x86_64-mingw of your PR failed (pretty log, 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.
2019-11-13T18:18:33.0094465Z [RUSTC-TIMING] lazycell test:false 0.136
2019-11-13T18:18:33.0331688Z    Compiling hex v0.4.0
2019-11-13T18:18:36.6904782Z [RUSTC-TIMING] hex test:false 3.659
2019-11-13T18:18:36.6976132Z    Compiling glob v0.3.0
2019-11-13T18:18:37.1936359Z memory allocation of 4294967304 bytes failed[RUSTC-TIMING] hex test:false 4.536
2019-11-13T18:18:37.1989695Z error: could not compile `hex`.
2019-11-13T18:18:37.1990887Z Caused by:
2019-11-13T18:18:37.1990887Z Caused by:
2019-11-13T18:18:37.1991486Z   process didn't exit successfully: `D:\a\1\s\build\bootstrap/debug/rustc --crate-name hex C:\Users\VssAdministrator\.cargo\registry\src\github.com-1ecc6299db9ec823\hex-0.3.2\src\lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C opt-level=2 -C debuginfo=0 -C metadata=d67f5eafaf62238d -C extra-filename=-d67f5eafaf62238d --out-dir D:\a\1\s\build\x86_64-pc-windows-gnu\stage1-tools\x86_64-pc-windows-gnu\release\deps --target x86_64-pc-windows-gnu -L dependency=D:\a\1\s\build\x86_64-pc-windows-gnu\stage1-tools\x86_64-pc-windows-gnu\release\deps -L dependency=D:\a\1\s\build\x86_64-pc-windows-gnu\stage1-tools\release\deps --cap-lints allow -Zexternal-macro-backtrace -Zbinary-dep-depinfo` (exit code: 0xc0000409, STATUS_STACK_BUFFER_OVERRUN)
2019-11-13T18:18:38.6403915Z [RUSTC-TIMING] glob test:false 1.925
2019-11-13T18:18:38.6571415Z error: build failed
2019-11-13T18:18:38.6617757Z command did not execute successfully: "D:\\a\\1\\s\\build\\x86_64-pc-windows-gnu\\stage0\\bin\\cargo.exe" "build" "-Zconfig-profile" "--target" "x86_64-pc-windows-gnu" "-Zbinary-dep-depinfo" "-j" "2" "--release" "--locked" "--color" "always" "--manifest-path" "D:\\a\\1\\s\\src/tools/cargo\\Cargo.toml" "--features" "rustc-workspace-hack/all-static" "--message-format" "json-render-diagnostics"
2019-11-13T18:18:38.6619389Z expected success, got: exit code: 101
2019-11-13T18:18:38.6619389Z expected success, got: exit code: 101
2019-11-13T18:18:38.7636655Z failed to run: D:\a\1\s\build\bootstrap\debug\bootstrap dist
2019-11-13T18:18:38.7637098Z Build completed unsuccessfully in 1:49:45
2019-11-13T18:18:38.7886708Z == clock drift check ==
2019-11-13T18:18:38.8796453Z   local time: Wed Nov 13 18:18:38 CUT 2019
2019-11-13T18:18:39.3940811Z   network time: Wed, 13 Nov 2019 18:18:39 GMT
2019-11-13T18:18:39.3952820Z == end clock drift check ==
2019-11-13T18:18:39.4831406Z 
2019-11-13T18:18:39.8868888Z ##[error]Bash exited with code '1'.
2019-11-13T18:18:39.9415037Z ##[section]Starting: Checkout
2019-11-13T18:18:40.0229478Z ==============================================================================
2019-11-13T18:18:40.0229643Z Task         : Get sources
2019-11-13T18:18:40.0229720Z Description  : Get sources from a repository. Supports Git, TfsVC, and SVN repositories.

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)

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Nov 13, 2019

💔 Test failed - checks-azure

@gnzlbg

This comment has been minimized.

Copy link
Contributor Author

gnzlbg commented Nov 14, 2019

memory allocation of 4294967304 bytes failed

That's an attempt to allocate 4.29 Gbs, how much memory do the Azure VMs have? Is this the only PR running into this issue? (that might hint that this PR introduces a memory leak maybe?)

@alexcrichton

This comment has been minimized.

Copy link
Member

alexcrichton commented Nov 15, 2019

@bors: retry

#66342

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Nov 15, 2019

⌛️ Testing commit 6da4df9 with merge 9e8c4e6...

bors added a commit that referenced this pull request Nov 15, 2019
Make the semantics of Vec::truncate(N) consistent with slices.

This commit simplifies the implementation of `Vec::truncate(N)` and
makes its semantics identical to dropping the `[vec.len() - N..]`
sub-slice tail of the vector, which is the same behavior as dropping a
vector containing the same sub-slice.

This changes two unspecified aspects of `Vec::truncate` behavior:

* the drop order, from back-to-front to front-to-back,
* the behavior of `Vec::truncate` on panics: if dropping one element of
  the tail panics, currently, `Vec::truncate` panics, but with this PR all other
  elements are still dropped, and if dropping a second element of the tail
  panics, with this PR, the program aborts.

Programs can trivially observe both changes. For example
([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=7bef575b83b06e82b3e3529e4edbcac7)):

```rust
fn main() {
    struct Bomb(usize);
    impl Drop for Bomb {
        fn drop(&mut self) {
            panic!(format!("{}", self.0));
        }
    }
    let mut v = vec![Bomb(0), Bomb(1)];
    std::panic::catch_unwind(std::panic::AssertUnwindSafe(|| {
        v.truncate(0);
    }));
    assert_eq!(v.len(), 1);
    std::mem::forget(v);
}
```

panics printing `1` today and succeeds. With this change, it panics
printing `0` first (due to the drop order change), and then aborts
with a double-panic printing `1`, just like dropping the
`[Bomb(0), Bomb(1)]` slice does, or dropping
`vec![Bomb(0), Bomb(1)]` does.

This needs to go through a crater run.

r? @SimonSapin
@bors

This comment has been minimized.

Copy link
Contributor

bors commented Nov 15, 2019

☀️ Test successful - checks-azure
Approved by: alexcrichton
Pushing 9e8c4e6 to master...

@bors bors added the merged-by-bors label Nov 15, 2019
@bors bors merged commit 6da4df9 into rust-lang:master Nov 15, 2019
5 checks passed
5 checks passed
homu Test successful
Details
pr Build #20190915.8 succeeded
Details
pr (Linux mingw-check) Linux mingw-check succeeded
Details
pr (Linux x86_64-gnu-llvm-6.0) Linux x86_64-gnu-llvm-6.0 succeeded
Details
pr (LinuxTools) LinuxTools succeeded
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.