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

Implement DoubleEndedIterator for iter::{StepBy, Peekable, Take} #61457

Merged
merged 1 commit into from Aug 6, 2019

Conversation

@timvermeulen
Copy link
Contributor

commented Jun 2, 2019

Now that DoubleEndedIterator::nth_back has landed, StepBy and Take can have an efficient DoubleEndedIterator implementation. I don't know if there was any particular reason for Peekable not having a DoubleEndedIterator implementation, but it's quite trivial and I don't see any drawbacks to having it.

I'm not very happy about the implementation of Peekable::try_rfold, but I didn't see another way to only take the value out of self.peeked in case self.iter.try_rfold didn't exit early.

I only added Peekable::rfold (in addition to try_rfold) because its Iterator implementation has both fold and try_fold (and for similar reasons I added Take::try_rfold but not Take::rfold). Do we have any guidelines on whether we want both? If we do want both, maybe we should investigate which iterator adaptors override try_fold but not fold and add the missing implementations. At the moment I think that it's better to always have iterator adaptors implement both, because some iterators have a simpler fold implementation than their try_fold implementation.

The tests that I added may not be sufficient because they're all just existing tests where next/nth/fold/try_fold are replaced by their DEI counterparts, but I do think all paths are covered. Is there anything in particular that I should probably also test?

@rust-highfive

This comment has been minimized.

Copy link
Collaborator

commented Jun 2, 2019

r? @kennytm

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

@rust-highfive

This comment has been minimized.

Copy link
Collaborator

commented Jun 2, 2019

The job x86_64-gnu-llvm-6.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:05e0c770:start=1559476913973595770,finish=1559476915977649711,duration=2004053941
$ 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
$ export GCP_CACHE_BUCKET=rust-lang-ci-cache
$ export AWS_ACCESS_KEY_ID=AKIA46X5W6CZEJZ6XT55
---
[00:04:42] tidy error: /checkout/src/libcore/tests/iter.rs:903: trailing whitespace
[00:04:47] some tidy checks failed
[00:04:47] 
[00:04:47] 
[00:04:47] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:04:47] 
[00:04:47] 
[00:04:47] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:04:47] Build completed unsuccessfully in 0:01:14
---
travis_time:end:0015c48c:start=1559477216064562327,finish=1559477216069687930,duration=5125603
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:36606ce6
$ 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:007a8730
travis_time:start:007a8730
$ 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:02421694
$ 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)

}
}

#[unstable(feature = "double_ended_step_by_iterator", issue = "0")]

This comment has been minimized.

Copy link
@kennytm

kennytm Jun 2, 2019

Member

An impl is unfortunately insta-stable.

@kennytm

This comment has been minimized.

Copy link
Member

commented Jun 2, 2019

@rust-highfive rust-highfive assigned scottmcm and unassigned kennytm Jun 2, 2019
@timvermeulen timvermeulen force-pushed the timvermeulen:double_ended_iters branch from 4103254 to dd17a6b Jun 2, 2019
impl<I> DoubleEndedIterator for Peekable<I> where I: DoubleEndedIterator {
#[inline]
fn next_back(&mut self) -> Option<Self::Item> {
self.iter.next_back().or_else(|| self.peeked.take().and_then(|x| x))

This comment has been minimized.

Copy link
@scottmcm

scottmcm Jun 2, 2019

Member

If Peekable is going to be DEI, then should it have a peek_back() too? But that has space cost, which might be why it wasn't already double-ended?

This comment has been minimized.

Copy link
@timvermeulen

timvermeulen Jun 2, 2019

Author Contributor

Yeah, that may be why this implementation was missing, but I don't think it needs to have a peek_back() method for it to be useful as a DEI. If anyone needs to be able to peek from both sides, a separate type would probably make more sense because of the memory implications you mentioned.

The only surprising thing about it being a DEI would perhaps be that nth_back can't be implemented efficiently.

@scottmcm

This comment has been minimized.

Copy link
Member

commented Jun 2, 2019

Is there anything in particular that I should probably also test?

Your tryfolds look pretty good, but because I've seen so many with short-circuiting issues, could you add some very blatant short-circuit-every-step tests? For example,

    let mut it = (2..20).take(3);
    assert_eq!(it.try_for_each(Err), Err(2));
    assert_eq!(it.try_for_each(Err), Err(3));
    assert_eq!(it.try_for_each(Err), Err(4));
    assert_eq!(it.try_for_each(Err), Ok(()));

    let mut it = (2..20).take(3).rev();
    assert_eq!(it.try_for_each(Err), Err(4));
    assert_eq!(it.try_for_each(Err), Err(3));
    assert_eq!(it.try_for_each(Err), Err(2));
    assert_eq!(it.try_for_each(Err), Ok(()));

(Basically the same as the .next()-repeatedly tests, just spelling .next() as .try_for_each(Err).err() and .next_back() as .try_rfold((), |_, x| Err(x)).err() 🙂)

@timvermeulen

This comment has been minimized.

Copy link
Contributor Author

commented Jun 2, 2019

@scottmcm Good idea, something like this?


#[inline]
fn nth_back(&mut self, n: usize) -> Option<Self::Item> {
self.iter.nth_back(self.next_back_index() + n * (self.step + 1))

This comment has been minimized.

Copy link
@ollie27

ollie27 Jun 5, 2019

Contributor

Couldn't this multiplication and addition overflow?

This comment has been minimized.

Copy link
@timvermeulen

timvermeulen Jun 5, 2019

Author Contributor

Ah, I naively assumed that n would be in-bounds here. Thanks!

@timvermeulen timvermeulen force-pushed the timvermeulen:double_ended_iters branch from db28457 to c79eaaa Jun 5, 2019
@scottmcm

This comment has been minimized.

Copy link
Member

commented Jun 20, 2019

Nominating to see if libs in interested in these.

@timvermeulen timvermeulen force-pushed the timvermeulen:double_ended_iters branch from c79eaaa to 56ebfb1 Jul 9, 2019
@alexcrichton

This comment has been minimized.

Copy link
Member

commented Jul 10, 2019

Sorry for the delay on the libs side of things, but the libs team discussed this today and is ok adding these impls, so feel free to r+ when ready @scottmcm!

@scottmcm

This comment has been minimized.

Copy link
Member

commented Jul 10, 2019

@alexcrichton Doesn't this need an FCP because it's adding insta-stable impls?

@alexcrichton

This comment has been minimized.

Copy link
Member

commented Jul 11, 2019

Sure, can go through that as well!

@rfcbot fcp merge

@Centril Centril added this to the 1.38 milestone Jul 21, 2019
@Centril

This comment has been minimized.

Copy link
Member

commented Jul 25, 2019

@rfcbot

This comment has been minimized.

Copy link

commented Jul 25, 2019

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

@scottmcm

This comment has been minimized.

Copy link
Member

commented Jul 27, 2019

(r=me when the FCP completes in a week)

@rfcbot

This comment has been minimized.

Copy link

commented Aug 4, 2019

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

@Centril

This comment has been minimized.

Copy link
Member

commented Aug 4, 2019

@bors r=scottmcm rollup

@bors

This comment has been minimized.

Copy link
Contributor

commented Aug 4, 2019

📌 Commit 56ebfb1 has been approved by scottmcm

Centril added a commit to Centril/rust that referenced this pull request Aug 5, 2019
…scottmcm

Implement DoubleEndedIterator for iter::{StepBy, Peekable, Take}

Now that `DoubleEndedIterator::nth_back` has landed, `StepBy` and `Take` can have an efficient `DoubleEndedIterator` implementation. I don't know if there was any particular reason for `Peekable` not having a `DoubleEndedIterator` implementation, but it's quite trivial and I don't see any drawbacks to having it.

I'm not very happy about the implementation of `Peekable::try_rfold`, but I didn't see another way to only take the value out of `self.peeked` in case `self.iter.try_rfold` didn't exit early.

I only added `Peekable::rfold` (in addition to `try_rfold`) because its `Iterator` implementation has both `fold` and `try_fold` (and for similar reasons I added `Take::try_rfold` but not `Take::rfold`). Do we have any guidelines on whether we want both? If we do want both, maybe we should investigate which iterator adaptors override `try_fold` but not `fold` and add the missing implementations. At the moment I think that it's better to always have iterator adaptors implement both, because some iterators have a simpler `fold` implementation than their `try_fold` implementation.

The tests that I added may not be sufficient because they're all just existing tests where `next`/`nth`/`fold`/`try_fold` are replaced by their DEI counterparts, but I do think all paths are covered. Is there anything in particular that I should probably also test?
bors added a commit that referenced this pull request Aug 5, 2019
Rollup of 14 pull requests

Successful merges:

 - #61457 (Implement DoubleEndedIterator for iter::{StepBy, Peekable, Take})
 - #62987 (Add {IoSlice, IoSliceMut}::advance)
 - #63017 (Remove special code-path for handing unknown tokens)
 - #63152 (Always error on `SizeOverflow` during mir evaluation)
 - #63184 (Explaining the reason why validation is performed in to_str of path.rs)
 - #63250 (diagnostics: Describe crate root modules in `DefKind::Mod` as "crate")
 - #63259 (Add tests for some issues)
 - #63260 (fix UB in a test)
 - #63264 (Revert "Rollup merge of #62696 - chocol4te:fix_#62194, r=estebank")
 - #63272 (Some more libsyntax::attr cleanup)
 - #63285 (Remove leftover AwaitOrigin)
 - #63287 (Don't store &Span)
 - #63295 (improve align_offset docs)
 - #63299 (Make qualify consts in_projection use PlaceRef)

Failed merges:

r? @ghost
Centril added a commit to Centril/rust that referenced this pull request Aug 6, 2019
…scottmcm

Implement DoubleEndedIterator for iter::{StepBy, Peekable, Take}

Now that `DoubleEndedIterator::nth_back` has landed, `StepBy` and `Take` can have an efficient `DoubleEndedIterator` implementation. I don't know if there was any particular reason for `Peekable` not having a `DoubleEndedIterator` implementation, but it's quite trivial and I don't see any drawbacks to having it.

I'm not very happy about the implementation of `Peekable::try_rfold`, but I didn't see another way to only take the value out of `self.peeked` in case `self.iter.try_rfold` didn't exit early.

I only added `Peekable::rfold` (in addition to `try_rfold`) because its `Iterator` implementation has both `fold` and `try_fold` (and for similar reasons I added `Take::try_rfold` but not `Take::rfold`). Do we have any guidelines on whether we want both? If we do want both, maybe we should investigate which iterator adaptors override `try_fold` but not `fold` and add the missing implementations. At the moment I think that it's better to always have iterator adaptors implement both, because some iterators have a simpler `fold` implementation than their `try_fold` implementation.

The tests that I added may not be sufficient because they're all just existing tests where `next`/`nth`/`fold`/`try_fold` are replaced by their DEI counterparts, but I do think all paths are covered. Is there anything in particular that I should probably also test?
bors added a commit that referenced this pull request Aug 6, 2019
Rollup of 14 pull requests

Successful merges:

 - #61457 (Implement DoubleEndedIterator for iter::{StepBy, Peekable, Take})
 - #63017 (Remove special code-path for handing unknown tokens)
 - #63184 (Explaining the reason why validation is performed in to_str of path.rs)
 - #63230 (Make use of possibly uninitialized data [E0381] a hard error)
 - #63250 (diagnostics: Describe crate root modules in `DefKind::Mod` as "crate")
 - #63259 (Add tests for some issues)
 - #63260 (fix UB in a test)
 - #63264 (Revert "Rollup merge of #62696 - chocol4te:fix_#62194, r=estebank")
 - #63272 (Some more libsyntax::attr cleanup)
 - #63285 (Remove leftover AwaitOrigin)
 - #63287 (Don't store &Span)
 - #63293 (Clarify align_to's requirements and obligations)
 - #63295 (improve align_offset docs)
 - #63299 (Make qualify consts in_projection use PlaceRef)

Failed merges:

r? @ghost
Centril added a commit to Centril/rust that referenced this pull request Aug 6, 2019
…scottmcm

Implement DoubleEndedIterator for iter::{StepBy, Peekable, Take}

Now that `DoubleEndedIterator::nth_back` has landed, `StepBy` and `Take` can have an efficient `DoubleEndedIterator` implementation. I don't know if there was any particular reason for `Peekable` not having a `DoubleEndedIterator` implementation, but it's quite trivial and I don't see any drawbacks to having it.

I'm not very happy about the implementation of `Peekable::try_rfold`, but I didn't see another way to only take the value out of `self.peeked` in case `self.iter.try_rfold` didn't exit early.

I only added `Peekable::rfold` (in addition to `try_rfold`) because its `Iterator` implementation has both `fold` and `try_fold` (and for similar reasons I added `Take::try_rfold` but not `Take::rfold`). Do we have any guidelines on whether we want both? If we do want both, maybe we should investigate which iterator adaptors override `try_fold` but not `fold` and add the missing implementations. At the moment I think that it's better to always have iterator adaptors implement both, because some iterators have a simpler `fold` implementation than their `try_fold` implementation.

The tests that I added may not be sufficient because they're all just existing tests where `next`/`nth`/`fold`/`try_fold` are replaced by their DEI counterparts, but I do think all paths are covered. Is there anything in particular that I should probably also test?
bors added a commit that referenced this pull request Aug 6, 2019
Rollup of 14 pull requests

Successful merges:

 - #61457 (Implement DoubleEndedIterator for iter::{StepBy, Peekable, Take})
 - #63017 (Remove special code-path for handing unknown tokens)
 - #63184 (Explaining the reason why validation is performed in to_str of path.rs)
 - #63230 (Make use of possibly uninitialized data [E0381] a hard error)
 - #63250 (diagnostics: Describe crate root modules in `DefKind::Mod` as "crate")
 - #63260 (fix UB in a test)
 - #63264 (Revert "Rollup merge of #62696 - chocol4te:fix_#62194, r=estebank")
 - #63272 (Some more libsyntax::attr cleanup)
 - #63285 (Remove leftover AwaitOrigin)
 - #63287 (Don't store &Span)
 - #63293 (Clarify align_to's requirements and obligations)
 - #63295 (improve align_offset docs)
 - #63299 (Make qualify consts in_projection use PlaceRef)
 - #63312 (doc: fix broken sentence)

Failed merges:

r? @ghost
Centril added a commit to Centril/rust that referenced this pull request Aug 6, 2019
…scottmcm

Implement DoubleEndedIterator for iter::{StepBy, Peekable, Take}

Now that `DoubleEndedIterator::nth_back` has landed, `StepBy` and `Take` can have an efficient `DoubleEndedIterator` implementation. I don't know if there was any particular reason for `Peekable` not having a `DoubleEndedIterator` implementation, but it's quite trivial and I don't see any drawbacks to having it.

I'm not very happy about the implementation of `Peekable::try_rfold`, but I didn't see another way to only take the value out of `self.peeked` in case `self.iter.try_rfold` didn't exit early.

I only added `Peekable::rfold` (in addition to `try_rfold`) because its `Iterator` implementation has both `fold` and `try_fold` (and for similar reasons I added `Take::try_rfold` but not `Take::rfold`). Do we have any guidelines on whether we want both? If we do want both, maybe we should investigate which iterator adaptors override `try_fold` but not `fold` and add the missing implementations. At the moment I think that it's better to always have iterator adaptors implement both, because some iterators have a simpler `fold` implementation than their `try_fold` implementation.

The tests that I added may not be sufficient because they're all just existing tests where `next`/`nth`/`fold`/`try_fold` are replaced by their DEI counterparts, but I do think all paths are covered. Is there anything in particular that I should probably also test?
bors added a commit that referenced this pull request Aug 6, 2019
Rollup of 14 pull requests

Successful merges:

 - #61457 (Implement DoubleEndedIterator for iter::{StepBy, Peekable, Take})
 - #63017 (Remove special code-path for handing unknown tokens)
 - #63184 (Explaining the reason why validation is performed in to_str of path.rs)
 - #63230 (Make use of possibly uninitialized data [E0381] a hard error)
 - #63260 (fix UB in a test)
 - #63264 (Revert "Rollup merge of #62696 - chocol4te:fix_#62194, r=estebank")
 - #63272 (Some more libsyntax::attr cleanup)
 - #63285 (Remove leftover AwaitOrigin)
 - #63287 (Don't store &Span)
 - #63293 (Clarify align_to's requirements and obligations)
 - #63295 (improve align_offset docs)
 - #63299 (Make qualify consts in_projection use PlaceRef)
 - #63312 (doc: fix broken sentence)
 - #63315 (Fix #63313)

Failed merges:

r? @ghost
@bors bors merged commit 56ebfb1 into rust-lang:master Aug 6, 2019
3 checks passed
3 checks passed
pr Build #20190709.63 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
netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this pull request Oct 2, 2019
Pkgsrc changes:
 * Adapt to the move of the implementation of random numbers.
 * Remove patch which is no longer relevant (Signals.inc)
 * Cross-build currently fails due to the still unresolved
   rust-lang/rust#62558, so bootstrap
   kits for 1.38.0 have to be built natively, and will follow shortly.
 * Bump bootstrap requirements to 1.37.0 except for armv7-unknown-netbsd-eabihf
   which I've neither managed to cross-build nor build natively.

Upstream changes:

Version 1.38.0 (2019-09-26)
==========================

Language
--------
- [The `#[global_allocator]` attribute can now be used in submodules.][62735]
- [The `#[deprecated]` attribute can now be used on macros.][62042]

Compiler
--------
- [Added pipelined compilation support to `rustc`.][62766] This will
  improve compilation times in some cases. For further information please refer
  to the [_"Evaluating pipelined rustc compilation"_][pipeline-internals]
  thread.
- [Added tier 3\* support for the `aarch64-uwp-windows-msvc`,
  `i686-uwp-windows-gnu`, `i686-uwp-windows-msvc`, `x86_64-uwp-windows-gnu`,
  and `x86_64-uwp-windows-msvc` targets.][60260]
- [Added tier 3 support for the `armv7-unknown-linux-gnueabi` and
  `armv7-unknown-linux-musleabi` targets.][63107]
- [Added tier 3 support for the `hexagon-unknown-linux-musl` target.][62814]
- [Added tier 3 support for the `riscv32i-unknown-none-elf` target.][62784]

\* Refer to Rust's [platform support page][forge-platform-support] for more
information on Rust's tiered platform support.

Libraries
---------
- [`ascii::EscapeDefault` now implements `Clone` and `Display`.][63421]
- [Derive macros for prelude traits (e.g. `Clone`, `Debug`, `Hash`) are now
  available at the same path as the trait.][63056] (e.g. The `Clone` derive
  macro is available at `std::clone::Clone`). This also makes all built-in
  macros available in `std`/`core` root. e.g. `std::include_bytes!`.
- [`str::Chars` now implements `Debug`.][63000]
- [`slice::{concat, connect, join}` now accepts `&[T]` in addition to
   `&T`.][62528]
- [`*const T` and `*mut T` now implement `marker::Unpin`.][62583]
- [`Arc<[T]>` and `Rc<[T]>` now implement `FromIterator<T>`.][61953]
- [Added euclidean remainder and division operations (`div_euclid`,
  `rem_euclid`) to all numeric primitives.][61884] Additionally `checked`,
  `overflowing`, and `wrapping` versions are available for all
  integer primitives.
- [`thread::AccessError` now implements `Clone`, `Copy`, `Eq`, `Error`, and
  `PartialEq`.][61491]
- [`iter::{StepBy, Peekable, Take}` now implement `DoubleEndedIterator`.][61457]

Stabilized APIs
---------------
- [`<*const T>::cast`]
- [`<*mut T>::cast`]
- [`Duration::as_secs_f32`]
- [`Duration::as_secs_f64`]
- [`Duration::div_duration_f32`]
- [`Duration::div_duration_f64`]
- [`Duration::div_f32`]
- [`Duration::div_f64`]
- [`Duration::from_secs_f32`]
- [`Duration::from_secs_f64`]
- [`Duration::mul_f32`]
- [`Duration::mul_f64`]
- [`any::type_name`]

Cargo
-----
- [Added pipelined compilation support to `cargo`.][cargo/7143]
- [You can now pass the `--features` option multiple times to enable
  multiple features.][cargo/7084]

Misc
----
- [`rustc` will now warn about some incorrect uses of
  `mem::{uninitialized, zeroed}` that are known to cause undefined
  behaviour.][63346]

Compatibility Notes
-------------------
- Unfortunately the [`x86_64-unknown-uefi` platform can not be built][62785]
  with rustc 1.39.0.
- The [`armv7-unknown-linux-gnueabihf` platform is also known to have
  issues][62896] for certain crates such as libc.

[60260]: rust-lang/rust#60260
[61457]: rust-lang/rust#61457
[61491]: rust-lang/rust#61491
[61884]: rust-lang/rust#61884
[61953]: rust-lang/rust#61953
[62042]: rust-lang/rust#62042
[62528]: rust-lang/rust#62528
[62583]: rust-lang/rust#62583
[62735]: rust-lang/rust#62735
[62766]: rust-lang/rust#62766
[62784]: rust-lang/rust#62784
[62785]: rust-lang/rust#62785
[62814]: rust-lang/rust#62814
[62896]: rust-lang/rust#62896
[63000]: rust-lang/rust#63000
[63056]: rust-lang/rust#63056
[63107]: rust-lang/rust#63107
[63346]: rust-lang/rust#63346
[63421]: rust-lang/rust#63421
[cargo/7084]: rust-lang/cargo#7084
[cargo/7143]: rust-lang/cargo#7143
[`<*const T>::cast`]: https://doc.rust-lang.org/std/primitive.pointer.html#method.cast
[`<*mut T>::cast`]: https://doc.rust-lang.org/std/primitive.pointer.html#method.cast
[`Duration::as_secs_f32`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.as_secs_f32
[`Duration::as_secs_f64`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.as_secs_f64
[`Duration::div_duration_f32`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.div_duration_f32
[`Duration::div_duration_f64`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.div_duration_f64
[`Duration::div_f32`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.div_f32
[`Duration::div_f64`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.div_f64
[`Duration::from_secs_f32`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.from_secs_f32
[`Duration::from_secs_f64`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.from_secs_f64
[`Duration::mul_f32`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.mul_f32
[`Duration::mul_f64`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.mul_f64
[`any::type_name`]: https://doc.rust-lang.org/std/any/fn.type_name.html
[forge-platform-support]: https://forge.rust-lang.org/platform-support.html
[pipeline-internals]: https://internals.rust-lang.org/t/evaluating-pipelined-rustc-compilation/10199
netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this pull request Oct 18, 2019
Pkgsrc changes:
 * Adapt to the move of the implementation of random numbers.
 * Remove patch which is no longer relevant (Signals.inc)
 * Cross-build currently fails due to the still unresolved
   rust-lang/rust#62558, so bootstrap
   kits for 1.38.0 have to be built natively, and will follow shortly.
 * Bump bootstrap requirements to 1.37.0 except for armv7-unknown-netbsd-eabihf
   which I've neither managed to cross-build nor build natively.

Upstream changes:

Version 1.38.0 (2019-09-26)
==========================

Language
--------
- [The `#[global_allocator]` attribute can now be used in submodules.][62735]
- [The `#[deprecated]` attribute can now be used on macros.][62042]

Compiler
--------
- [Added pipelined compilation support to `rustc`.][62766] This will
  improve compilation times in some cases. For further information please refer
  to the [_"Evaluating pipelined rustc compilation"_][pipeline-internals]
  thread.
- [Added tier 3\* support for the `aarch64-uwp-windows-msvc`,
  `i686-uwp-windows-gnu`, `i686-uwp-windows-msvc`, `x86_64-uwp-windows-gnu`,
  and `x86_64-uwp-windows-msvc` targets.][60260]
- [Added tier 3 support for the `armv7-unknown-linux-gnueabi` and
  `armv7-unknown-linux-musleabi` targets.][63107]
- [Added tier 3 support for the `hexagon-unknown-linux-musl` target.][62814]
- [Added tier 3 support for the `riscv32i-unknown-none-elf` target.][62784]

\* Refer to Rust's [platform support page][forge-platform-support] for more
information on Rust's tiered platform support.

Libraries
---------
- [`ascii::EscapeDefault` now implements `Clone` and `Display`.][63421]
- [Derive macros for prelude traits (e.g. `Clone`, `Debug`, `Hash`) are now
  available at the same path as the trait.][63056] (e.g. The `Clone` derive
  macro is available at `std::clone::Clone`). This also makes all built-in
  macros available in `std`/`core` root. e.g. `std::include_bytes!`.
- [`str::Chars` now implements `Debug`.][63000]
- [`slice::{concat, connect, join}` now accepts `&[T]` in addition to
   `&T`.][62528]
- [`*const T` and `*mut T` now implement `marker::Unpin`.][62583]
- [`Arc<[T]>` and `Rc<[T]>` now implement `FromIterator<T>`.][61953]
- [Added euclidean remainder and division operations (`div_euclid`,
  `rem_euclid`) to all numeric primitives.][61884] Additionally `checked`,
  `overflowing`, and `wrapping` versions are available for all
  integer primitives.
- [`thread::AccessError` now implements `Clone`, `Copy`, `Eq`, `Error`, and
  `PartialEq`.][61491]
- [`iter::{StepBy, Peekable, Take}` now implement `DoubleEndedIterator`.][61457]

Stabilized APIs
---------------
- [`<*const T>::cast`]
- [`<*mut T>::cast`]
- [`Duration::as_secs_f32`]
- [`Duration::as_secs_f64`]
- [`Duration::div_duration_f32`]
- [`Duration::div_duration_f64`]
- [`Duration::div_f32`]
- [`Duration::div_f64`]
- [`Duration::from_secs_f32`]
- [`Duration::from_secs_f64`]
- [`Duration::mul_f32`]
- [`Duration::mul_f64`]
- [`any::type_name`]

Cargo
-----
- [Added pipelined compilation support to `cargo`.][cargo/7143]
- [You can now pass the `--features` option multiple times to enable
  multiple features.][cargo/7084]

Misc
----
- [`rustc` will now warn about some incorrect uses of
  `mem::{uninitialized, zeroed}` that are known to cause undefined
  behaviour.][63346]

Compatibility Notes
-------------------
- Unfortunately the [`x86_64-unknown-uefi` platform can not be built][62785]
  with rustc 1.39.0.
- The [`armv7-unknown-linux-gnueabihf` platform is also known to have
  issues][62896] for certain crates such as libc.

[60260]: rust-lang/rust#60260
[61457]: rust-lang/rust#61457
[61491]: rust-lang/rust#61491
[61884]: rust-lang/rust#61884
[61953]: rust-lang/rust#61953
[62042]: rust-lang/rust#62042
[62528]: rust-lang/rust#62528
[62583]: rust-lang/rust#62583
[62735]: rust-lang/rust#62735
[62766]: rust-lang/rust#62766
[62784]: rust-lang/rust#62784
[62785]: rust-lang/rust#62785
[62814]: rust-lang/rust#62814
[62896]: rust-lang/rust#62896
[63000]: rust-lang/rust#63000
[63056]: rust-lang/rust#63056
[63107]: rust-lang/rust#63107
[63346]: rust-lang/rust#63346
[63421]: rust-lang/rust#63421
[cargo/7084]: rust-lang/cargo#7084
[cargo/7143]: rust-lang/cargo#7143
[`<*const T>::cast`]: https://doc.rust-lang.org/std/primitive.pointer.html#method.cast
[`<*mut T>::cast`]: https://doc.rust-lang.org/std/primitive.pointer.html#method.cast
[`Duration::as_secs_f32`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.as_secs_f32
[`Duration::as_secs_f64`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.as_secs_f64
[`Duration::div_duration_f32`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.div_duration_f32
[`Duration::div_duration_f64`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.div_duration_f64
[`Duration::div_f32`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.div_f32
[`Duration::div_f64`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.div_f64
[`Duration::from_secs_f32`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.from_secs_f32
[`Duration::from_secs_f64`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.from_secs_f64
[`Duration::mul_f32`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.mul_f32
[`Duration::mul_f64`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.mul_f64
[`any::type_name`]: https://doc.rust-lang.org/std/any/fn.type_name.html
[forge-platform-support]: https://forge.rust-lang.org/platform-support.html
[pipeline-internals]: https://internals.rust-lang.org/t/evaluating-pipelined-rustc-compilation/10199
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.