Add IntoIterator for Box<[T]> + edition 2024-specific lints by compiler-errors · Pull Request #124097 · rust-lang/rust (original) (raw)

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

compiler-errors

Based mostly off of #116607.

ACP: rust-lang/libs-team#263
References #59878
Tracking for Rust 2024: #123759

Crater run was done here: #116607 (comment)
Consensus afaict was that there is too much breakage, so let's do this in an edition-dependent way much like [T; N]: IntoIterator.

@rustbot

r? @oli-obk

rustbot has assigned @oli-obk.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

T-compiler

Relevant to the compiler team, which will review and decide on the PR/issue.

T-libs

Relevant to the library team, which will review and decide on the PR/issue.

labels

Apr 17, 2024

@rustbot

@compiler-errors compiler-errors added I-lang-nominated

Nominated for discussion during a lang team meeting.

I-libs-api-nominated

Nominated for discussion during a libs-api team meeting.

T-lang

Relevant to the language team, which will review and decide on the PR/issue.

T-libs-api

Relevant to the library API team, which will review and decide on the PR/issue.

S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

needs-fcp

This change is insta-stable, so needs a completed FCP to proceed.

and removed T-compiler

Relevant to the compiler team, which will review and decide on the PR/issue.

S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

T-libs

Relevant to the library team, which will review and decide on the PR/issue.

labels

Apr 17, 2024

@compiler-errors

Needs a T-compiler review of the impl first, then can go into FCP.

compiler-errors

@@ -184,7 +184,7 @@ impl<'a, T> IntoIterator for &'a P<[T]> {
type Item = &'a T;
type IntoIter = slice::Iter<'a, T>;
fn into_iter(self) -> Self::IntoIter {
self.ptr.into_iter()
self.ptr.iter()

Choose a reason for hiding this comment

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

Very funny to see somewhere in the compiler where we were relying on this behavior.

@rust-log-analyzer

This comment has been minimized.

@tmandry

I looked over the PR and I think we can kick off FCP in tandem with code review. The implementation includes a full migration that behaves as I'd expect.

@rust-lang/lang Are we okay with applying the same method resolution hack used for slices in 2021 to boxed slices in 2024?

@rust-lang/libs-api Are we okay with insta-stabilizing impl<T> IntoIterator for Box<[T]> and applying the method resolution hack?

@rfcbot fcp merge

@rfcbot

Team member @tmandry 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!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

@BurntSushi

The IntoIterator impl using vec::IntoIter<I, A> for Box<[T]> strikes me as a little odd, since Box<[T]> isn't a Vec. But I also can't necessarily come up with a specific concern with reusing the type other than "it seems weird."

@rustbot

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

@compiler-errors

For FCP folks, see some of the discussion in #116607 -- apparently reusing vec::IntoIter was discussed in a T-libs-api meeting and the consensus was that it was not desired to add a new type.

Also, this PR doesn't implement IntoIterator for Box<[T; N]>. That impl seems slightly less useful, since calling Box::new([1, 2, 3]).into_iter() already uses the IntoIterator for [T; N] impl via autoderef, so we already get an impl Iterator<Item = T>.

If anyone has a strong opinion, I could either add to this PR, or (ideally) add to this PR in a follow-up. It would only cause a breaking change when the user is relying on the exact array::Iter output type of [T; N], rather than the much larger fallout of this change.

@rust-log-analyzer

This comment has been minimized.

@clarfonthey

Also, this PR doesn't implement IntoIterator for Box<[T; N]>. That impl seems slightly less useful, since calling Box::new([1, 2, 3]).into_iter() already uses the IntoIterator for [T; N] impl via autoderef, so we already get an impl Iterator<Item = T>.

If anyone has a strong opinion, I could either add to this PR, or (ideally) add to this PR in a follow-up. It would only cause a breaking change when the user is relying on the exact array::Iter output type of [T; N], rather than the much larger fallout of this change.

My personal opinion here is that it would be desirable to have a heap-based iterator here, since using the array implementation would copy the entire array onto the stack before iterating. It also helps avoid the weird discrepancy between Box<[T]> and Box<[T; N]> having different performance implications.

Worth noting that a lot of people will use Box<[T; N]> also instead of [T; N] when N is large because they want to avoid storing the array on the stack, and iterating over it by copying it to the stack would go against these desires.

bors added a commit to rust-lang-ci/rust that referenced this pull request

Apr 18, 2024

@bors

…=

[crate] Add Box<[T; N]>: IntoIterator without any method dispatch hacks

Unlike Box<[T]> (rust-lang#116607 (comment)), there's a much higher chance that this will not conflict with existing usages since it produces an iterator with the same type before/after this change, but let's test that theory with crater.

Ideally we have fewer migrations that are tangled up in hacks like rustc_skip_during_method_dispatch, so if this crater comes back clean, I'd strongly suggest landing this as-is.

As for the rationale for having this impl at all, I agree (as @clarfonthey pointed out in rust-lang#124097 (comment)) that it is generally better for any user to not require moving the array out of the box just to turn it into an iterator.

@rustbot rustbot added the S-waiting-on-author

Status: This is awaiting some action (such as code changes or more information) from the author.

label

May 15, 2024

bors added a commit to rust-lang-ci/rust that referenced this pull request

May 15, 2024

@bors

…not-notable, r=fmease

rustdoc: Negative impls are not notable

In rust-lang#124097, we add impl !Iterator for [T] for coherence reasons, and since Iterator is a notable trait, this means that all -> &[_] now are tagged with a !Iterator impl as a notable trait.

I "fixed" the failing tests in that PR with 6cbbb8b, where I just blessed the tests, since I didn't want to mix these changes with that PR; however, don't believe negative impls are notable, and this PR aims to prevent these impls from being mentioned.

In the standard library, we use negative impls purely to guide coherence. They're not really a signal of anything useful to the end-user. If there ever is a case that we want negative impls to be mentioned as notable, this really should be an opt-in feature.

@bors

@compiler-errors

@compiler-errors @clarfonthey

Co-authored-by: ltdk usr@ltdk.xyz

@compiler-errors

@compiler-errors

@compiler-errors

@compiler-errors

@compiler-errors

@bors

📌 Commit 917bb83 has been approved by WaffleLapkin

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors

Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

and removed S-waiting-on-author

Status: This is awaiting some action (such as code changes or more information) from the author.

labels

May 21, 2024

@bors

@bors

@bors bors mentioned this pull request

May 21, 2024

@rust-timer

Finished benchmarking commit (e8fbd99): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean range count
Regressions ❌ (primary) - - 0
Regressions ❌ (secondary) 0.4% [0.3%, 0.5%] 4
Improvements ✅ (primary) - - 0
Improvements ✅ (secondary) - - 0
All ❌✅ (primary) - - 0

Max RSS (memory usage)

Results (primary -2.1%, secondary -3.4%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌ (primary) - - 0
Regressions ❌ (secondary) - - 0
Improvements ✅ (primary) -2.1% [-2.1%, -2.1%] 1
Improvements ✅ (secondary) -3.4% [-3.4%, -3.4%] 1
All ❌✅ (primary) -2.1% [-2.1%, -2.1%] 1

Cycles

Results (secondary -4.0%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌ (primary) - - 0
Regressions ❌ (secondary) - - 0
Improvements ✅ (primary) - - 0
Improvements ✅ (secondary) -4.0% [-4.0%, -4.0%] 1
All ❌✅ (primary) - - 0

Binary size

Results (secondary 0.0%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌ (primary) - - 0
Regressions ❌ (secondary) 0.0% [0.0%, 0.0%] 1
Improvements ✅ (primary) - - 0
Improvements ✅ (secondary) - - 0
All ❌✅ (primary) - - 0

Bootstrap: 669.761s -> 671.391s (0.24%)
Artifact size: 316.16 MiB -> 315.47 MiB (-0.22%)

@traviscross

@rustbot labels +relnotes

We discussed in the edition call today that this should probably go in the release notes for Rust 1.80.

@rustbot rustbot added the relnotes

Marks issues that should be documented in the release notes of the next release.

label

Jun 18, 2024

netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this pull request

Oct 13, 2024

@he32

This is based on the pkgsrc-wip rust180 package, retaining the main pkgsrc changes as best as I could.

Pkgsrc changes:

Upstream chnages:

Version 1.80.1 (2024-08-08)

Version 1.80.0 (2024-07-25)

Language

Compiler

Libraries

Stabilized APIs

These APIs are now stable in const contexts:

Cargo

Rustdoc

Compatibility Notes

Internal Changes

These changes do not affect any public interfaces of Rust, but they represent significant improvements to the performance or internals of rustc and related tools.

Version 1.79.0 (2024-06-13)

Language

Compiler

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

Libraries

Stabilized APIs

These APIs are now stable in const contexts:

Cargo

Rustdoc

Misc

Compatibility Notes

Version 1.78.0 (2024-05-02)

Language

Compiler

Target changes:

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

Libraries

Stabilized APIs

These APIs are now stable in const contexts:

Cargo

Misc

Compatibility Notes

Internal Changes

These changes do not affect any public interfaces of Rust, but they represent significant improvements to the performance or internals of rustc and related tools.

Version 1.77.0 (2024-03-21)

Compiler

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

Libraries

Stabilized APIs

Cargo

Rustdoc

Misc

Internal Changes

These changes do not affect any public interfaces of Rust, but they represent significant improvements to the performance or internals of rustc and related tools.

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.

merged-by-bors

This PR was explicitly merged by bors.

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.

S-waiting-on-bors

Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

T-lang

Relevant to the language team, which will review and decide on the PR/issue.

T-libs-api

Relevant to the library API team, which will review and decide on the PR/issue.