https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.18.0 2017-04-18T13:49:39+00:00 2017-04-18T13:49:39+00:00 Alex Crichton alex@alexcrichton.com 2017-03-20T21:13:27+00:00 urn:sha1:e46a8bde3c2ef7b1281f3d01e31febc687be2d12 It was discovered #40264 that this backtrace pruning logic is a little too aggressive, so while we figure how out to handle #40264 this commit backs out the changes to prune frames. Note that other cosmetic changes, such as better path printing and such remain. 2017-04-08T19:33:21+00:00 projektir oprojektir@gmail.com 2017-04-04T03:32:59+00:00 urn:sha1:28a232a59ac4ded4e6de9e9c06a17a801c5199dd 2017-03-30T11:51:16+00:00 Thomas Jespersen laumann.thomas@gmail.com 2017-03-17T22:11:27+00:00 urn:sha1:b3763862280946cab09cbedc4ad5626ebd95a5b2 Fixes #40149 2017-03-25T14:03:06+00:00 Marco A L Barbosa malbarbo@gmail.com 2017-03-17T11:06:23+00:00 urn:sha1:b45c631382a0bb831dc038973288e3f6d91cb07a 2017-03-17T12:49:02+00:00 Corey Farwell coreyf@rwell.org 2017-03-17T12:49:02+00:00 urn:sha1:d7a09d4e655871671a6c94c05a506ae3626ce528 std: remove a workaround for privacy limitations `std::thread::Thread` implements a non-exported `NewThread` trait to allow for internal-only use of `Thread::new`. Nowadays we have `pub(crate)`, which accomplishes the same thing but much more idiomatically. Rustdoc handles this correctly (I checked and I didn't see `Thread::new` on the rustdoc entry for `Thread` with this change), and the stage1 `rustc` emits the correct error still (I'm assuming that the stage1 compiler uses my `libstd`?): ``` $ ./build/x86_64-apple-darwin/stage1/bin/rustc test.rs error: method `new` is private --> test.rs:4:18 | 4 | let thread = thread::Thread::new(None); | ^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error ``` 2017-03-15T04:24:10+00:00 bors bors@rust-lang.org 2017-03-15T04:24:10+00:00 urn:sha1:71d7b29475225ae799f4906f3b50e06a7d323890 Leftovers from #39594; From<Box> impls These are a few more impls that follow the same reasoning as those from #39594. What's included: * `From<Box<str>> for String` * `From<Box<[T]>> for Vec<T>` * `From<Box<CStr>> for CString` * `From<Box<OsStr>> for OsString` * `From<Box<Path>> for PathBuf` * `Into<Box<str>> for String` * `Into<Box<[T]>> for Vec<T>` * `Into<Box<CStr>> for CString` * `Into<Box<OsStr>> for OsString` * `Into<Box<Path>> for PathBuf` * `<Box<CStr>>::into_c_string` * `<Box<OsStr>>::into_os_string` * `<Box<Path>>::into_path_buf` * Tracking issue for latter three methods + three from previous PR. Currently, the opposite direction isn't doable with `From` (only `Into`) because of the separation between `liballoc` and `libcollections`. I'm holding off on those for a later PR. 2017-03-14T01:42:23+00:00 Sean Gillespie sean@swgillespie.me 2017-03-14T01:42:23+00:00 urn:sha1:1545f4e2a323eb869b13f36bd05cc91ff21d5161 2017-03-11T04:05:06+00:00 Alex Crichton alex@alexcrichton.com 2017-03-10T22:51:46+00:00 urn:sha1:f4b4e097a6dcc5ffac6f3b34c91423708014c553 OsString::shrink_to_fit. Considering how the other capacity-related methods are there, I found it odd that this one wasn't included. Will create a tracking issue once I get an OK on this. 2017-03-10T19:57:57+00:00 Clar Charr clar@charr.xyz 2017-02-14T01:37:42+00:00 urn:sha1:560944b982385623655f1e8503af5e7b4ca0a436 2017-03-10T17:15:30+00:00 Clar Charr clar@charr.xyz 2017-03-10T05:23:54+00:00 urn:sha1:83814fd8ab30e2744d2fb17bdcf5b59840673863