stabilized iterator_for_each (closes #42986) by budziq · Pull Request #44567 · rust-lang/rust (original) (raw)

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 andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation20 Commits1 Checks0 Files changed

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 }})

Also updated clippy and rls as these use the iterator_for_each

I've made my first PR's today so most likely I've done something wrong. Sorry about that!

Failed to start the CI. Please update src/Cargo.lock.

[00:00:49] error: the lock file needs to be updated but --frozen was passed to prevent this

This needs to wait for completed FCP, right?

Looks great to me, thanks @budziq! Looks like some stray submodule updates were included though?

@cuviper yeah for APIs we don't wait for the FCP to end, we just go ahead and throw them in once the team has signed off.

Failed to start the CI. Please update src/Cargo.lock.

@kennytm Updated with Cargo.lock. Sorry about that!

Looks like some stray submodule updates were included though?

@alexcrichton The submodule updates were intentional due to rls and clipy depending on iterator_for_each. I've made PR's to their respective repos (rls, clippy) and updated the submodules to the PR commits according to this section in CONTRIBUTING.md

I might have misunderstood the instructions so I will be glad to fix any problems!

I might have misunderstood the instructions so I will be glad to fix any problems!

You're the first person to follow said instructions. Thanks!

If any problems show up with the process it's with the instructions and not you ;) Travis seems to like it so far.

📌 Commit b0655b1 has been approved by alexcrichton

@bors: r-

Er actually, we prefer that our submodules are attached to long-lived commits which are at least somewhat relatively guaranteed to stick around into the future. In that sense the section of the contributing docs is wrong I believe in that we don't want to pin our submodules to PRs.

Does stabilization here cause build failures? If not can the submodule updates happen later on the master branch?

Does stabilization here cause build failures?

The stabilization will cause build failure for rls and test failure in clippy. I believe that we have a chicken and egg problem here and the stabilization and submodule PR's should proceed in lockstep (submodules first to generate a long lived commit and shortly then the lang repo). But this is is actually a question to the maintainers 😄.

You can ignore clippy for now as we're not building it anyway, but for the rls we'll need to make a long-lived branch, which you can coordinate with @nrc for that

@nrc can you make a branch of the RLS for this?

📌 Commit 8772227 has been approved by alexcrichton

alexcrichton added a commit to alexcrichton/rust that referenced this pull request

Sep 16, 2017