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
Merged

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

merged 1 commit into from
Aug 6, 2019

Conversation

timvermeulen
Copy link
Contributor

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
Copy link
Collaborator

r? @kennytm

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

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 2, 2019
@rust-highfive
Copy link
Collaborator

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")]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An impl is unfortunately insta-stable.

@kennytm kennytm added needs-fcp This change is insta-stable, so needs a completed FCP to proceed. relnotes Marks issues that should be documented in the release notes of the next release. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Jun 2, 2019
@kennytm
Copy link
Member

kennytm commented Jun 2, 2019

r? @scottmcm

@rust-highfive rust-highfive assigned scottmcm and unassigned kennytm 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))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

scottmcm 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
Copy link
Contributor Author

@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))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couldn't this multiplication and addition overflow?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@scottmcm
Copy link
Member

Nominating to see if libs in interested in these.

@scottmcm scottmcm added S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 5, 2019
@alexcrichton
Copy link
Member

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!

@alexcrichton alexcrichton added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed I-nominated S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). needs-fcp This change is insta-stable, so needs a completed FCP to proceed. labels Jul 10, 2019
@scottmcm
Copy link
Member

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

@alexcrichton
Copy link
Member

Sure, can go through that as well!

@rfcbot fcp merge

@rfcbot
Copy link

rfcbot commented Jul 11, 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.

@rfcbot rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Jul 11, 2019
@Centril Centril added this to the 1.38 milestone Jul 21, 2019
@Centril
Copy link
Contributor

Centril commented Jul 25, 2019

ping @withoutboats @SimonSapin @Kimundi

@rfcbot rfcbot added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. labels Jul 25, 2019
@rfcbot
Copy link

rfcbot commented Jul 25, 2019

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

@scottmcm
Copy link
Member

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

@scottmcm scottmcm added S-waiting-on-fcp Status: PR is in FCP and is awaiting for FCP to complete. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 27, 2019
@rfcbot
Copy link

rfcbot 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.

@rfcbot rfcbot added finished-final-comment-period The final comment period is finished for this PR / Issue. and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Aug 4, 2019
@Centril Centril removed the S-waiting-on-fcp Status: PR is in FCP and is awaiting for FCP to complete. label Aug 4, 2019
@Centril
Copy link
Contributor

Centril commented Aug 4, 2019

@bors r=scottmcm rollup

@bors
Copy link
Contributor

bors commented Aug 4, 2019

📌 Commit 56ebfb1 has been approved by scottmcm

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Aug 4, 2019
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?
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?
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?
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
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
Labels
disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. relnotes Marks issues that should be documented in the release notes of the next release. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants