Remove impossible panic note from Vec::append

[tbu-]

Neither the number of elements in a vector can overflow a usize, nor
can the amount of elements in two vectors.

[rust-highfive]

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

[marmeladema]

What about ZST?

[tbu-]

All comments about ZST apply to Vec::push equally as well. Should I add a note here and to Vec::push about zero-sized types?

[Mark-Simulacrum]

I'm not sure I understand how ZST types are relevant here; I'm not seeing code that will panic on ZST types related to isize::MAX.

This change seems OK to me though, since it matches the reserve(...) panic note, and AFAICT that's the only source of panics for this method as well.

[tbu-]

I don't see anything to do for me. Did you add "S-waiting-on-author" by accident? @Mark-Simulacrum

[marmeladema]

I think the wording here (and in Vec::push) is confusing because it uses the term capacity which in this case is not related to the Vec::capacity method since for a ZST, Vec::capacity can be bigger than isize::MAX but no actual memory will be allocated:

fn main() {
        let mut vec = vec![(); usize::MAX];
        assert_eq!(vec.len(), usize::MAX);
        assert_eq!(vec.capacity(), usize::MAX);
        assert!(vec.capacity() > usize::try_from(isize::MAX).unwrap());
        vec.append(&mut vec![]);
        assert!(vec.capacity() > usize::try_from(isize::MAX).unwrap());
}

https://play.rust-lang.org/?version=stable&mode=release&edition=2021&gist=b75b2d890ed0f530ca925ff424f4246c

I would rather change both panic notes to use a different terminology like allocated memory with something for ZST that says no memory will be allocated.

[tbu-]

Note: It's also not directly related to the Vec::capacity method for other types, it's just for 1-byte large types where it corresponds 1-to-1. E.g. a 2-byte type can at most have isize::MAX / 2 capacity.

What replacement would you suggest?

Panics if the memory to be allocated would exceed isize::MAX bytes.

It seems to me that this would introduce another terminology and would thus make the note harder to understand.

[tbu-]

@JohnCSimon On what action of the author is the PR waiting on?

[JohnCSimon]

@tbu- triage just bumps the PR by adding + removing the tag so it shows that it was updated.

You can message the reviewer for clarification or talk on zulip.

FYI: when a PR is ready for review, send a message containing
@rustbot ready to switch to S-waiting-on-review so the PR is in the reviewer's backlog.

[tbu-]

@rustbot ready

[Mark-Simulacrum]

@bors r+ rollup

There may be further improvements to the language here but I don't think anything is blocking this PR at this point, so I'm going to go ahead and approve.

[bors]

📌 Commit 4123d33 has been approved by Mark-Simulacrum