Implement push_mut

[balt-dev]

Implementation of #135974.

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @ibraheemdev (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[balt-dev]

Sorry if I did this wrong, it's my first time!

[balt-dev]

A single trailing whitespace. Oops.

[ibraheemdev]

I'm not sure we should be touching Vec::push here.. maybe just duplicate the implementation?

[balt-dev]

Alright, I'll do that soon.

[balt-dev]

I finally got around to duplicating the implementation. College has been eating my time like a child with Halloween candy, sorry.

[balt-dev]

@rustbot review

[ibraheemdev]

I'm not sure I understand the point of this.

[balt-dev]

There should probably be a better example, yeah. Will update soon!

[alex-semenyuk]

@balt-dev
Thanks for your contribution
From wg-triage. Any updates on this PR?

[balt-dev]

I'm sorry, college has been quite a time sink for me and I haven't had the time to follow up as of recent - I will when I can, promise!

[balt-dev]

It's been a rough few months. ._.

[balt-dev]

hm.

[balt-dev]

I think I messed up my fork so bad I'll have to reset it and put my code in from scratch in order to get rid of the merge commit. At least it's copy/pasteable?

[balt-dev]

...again?

[balt-dev]

Sigh....

[balt-dev]

@traviscross How'd you fix the submodules?

[balt-dev]

Hm. I can't access anything here.

[tgross35]

@traviscross How'd you fix the submodules?

The easiest way is something like:

# Make sure you have rust-lang's `master` available
git remote add upstream https://github.com/rust-lang/rust.git
git fetch upstream master

# Do a soft reset to the point where you forked off from master.
# Mild warning: this will keep the diff but get rid of the new
# commits (the files will show up as having unstaged changes)
git reset "$(git merge-base HEAD upstream/master)"

# Just reset submodules
git submodule deinit --all --force

# Add the changes you actually want and create a new commit
git add library
git commit

# Update this PR, which will replace the three commits here with
# the one new commit
git push --force-with-lease

git rebase -i "$(git merge-base HEAD upstream/master)" will work in the future then , if you need to squash at some point.

For future reference, it's usually better practice to always work on branches rather than your fork's master so you can do git branch --set-upstream-to=upstream/master on your local master, then it will always track rust-lang/rust without needing to continually update your fork. But since this PR is from your master, don't do this until it merges :)

[bors]

☔ The latest upstream changes (presumably #142109) made this pull request unmergeable. Please resolve the merge conflicts.

[balt-dev]

That probably fixed the merge conflict.

[balt-dev]

@tgross35 Thank you so much!

[balt-dev]

Hm.

[balt-dev]

---- library/alloc/src/vec/mod.rs - vec::Vec<T,A>::push_mut (line 2572) stdout ----
error[E0614]: type `()` cannot be dereferenced
  --> library/alloc/src/vec/mod.rs:2579:1
   |
10 | *last = 4;
   | ^^^^^ can't be dereferenced

error: aborting due to 1 previous error

For more information about this error, try `rustc --explain E0614`.

Ah. @ibraheemdev The test you provided in the review was broken - it used push instead of push_mut.

[balt-dev]

@ibraheemdev ...did you even test that suggested test before suggesting it?

[tgross35]

@ibraheemdev ...did you even test that suggested test before suggesting it?

Please keep in mind that reviews are thoughtful and often suggest a general shape, but it's really up to the PR author to make sure they work and tweak them as needed. Reviewers won't be checking out and building your branch.

It's reasonably easy to run tests locally, ./x t library/alloc from the repo root should test what you need (note this may take a while to build the first time). Otherwise relying on CI is fine, that just means a slightly slower feedback loop.

[balt-dev]

Yeah, @ibraheemdev sorry for lashing out.
The problem is, tests take at least 10 minutes on my old laptop even when narrowing down as much as I can (./x.py test --doc --keep-stage 1 --stage 0 library/alloc), and CI is worse on that front, so it's tough to go back and forth on this.