Better handle increasing vector size near usize::MAX

[ghost]

Right now, if the user requests to increase the vector size via reserve() or push_back() and the request brings the attempted memory above usize::MAX, we panic.

With this change there is only a panic if the minimum requested memory that could meet the requirement is above usize::MAX- otherwise it simply requests its largest capacity possible, usize::MAX.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @pcwalton (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see CONTRIBUTING.md for more information.

[huonw]

I believe the largest allocation we fundamentally support is isize::MAX, so maybe this could be adjusted to use that limit instead?

[ghost]

Are you sure? In the current version of the source https://github.com/rust-lang/rust/blob/master/src/libcollections/vec.rs there's a lot of code that acts like usize::MAX is the max allowed, eg lines 209, 309, 337, 643, 655, 716, 1232.

If isize::MAX is the max allowed allocation then there are a lot of changes needed. Though these other lines could be handled in a different PR. (Also doesn't restricting to isize::MAX seem a bit limiting on 32 bit and smaller architectures?)

[huonw]

I guess Vec hasn't been updated for that rule (the restriction was only added relatively recently). The restriction is to ensure that isize can always represent the difference between two valid pointers into an "object" without overflow. (As you say, it is a bit limiting on small architectures but not overly so: there can only be one allocation larger than isize::MAX anyway.)

[ghost]

Gotcha, sounds good. I'll fix these instances up tomorrow, would you like me to include the other parts of the file I found above in this PR as well, or submit a different one?

[ghost]

Made these locations max out as isize::MAX. I added a fixme comment to fix the rest of the file to also assume isize::MAX is the max size, I'll fix those as well after the PR.

[pnkfelix]

r? @pnkfelix

[pnkfelix]

@bors r+

[bors]

📌 Commit f8493d0 has been approved by pnkfelix

[bors]

⌛️ Testing commit f8493d0 with merge f156c61...

[bors]

💔 Test failed - auto-linux-32-opt

[pnkfelix]

That compile failure is ... worrisome. I wonder if a bug has been injected very recently

[pnkfelix]

Or maybe I misunderstood a recent discussion of how general unary panic! actually is...

Cc @alexcrichton

[pnkfelix]

(The workaround should be easy, in any case,.. use static (or maybe const) instead of let. but i do think this represents an injected bug -- I'm trying to verify that now)

[pnkfelix]

(or wait, maybe this is just an issue where the panic! macro in libcore is not as full-featured as the one in libstd ... but I do not understand, @bcoopers , I assume that you were able to actually compile this code before, right?)

[ghost]

Yeah it compiled and the tests passed... Not sure what the problem is.

[ghost]

I just checked again on my local version, whose most recent commit is

commit fa3d778
Merge: 227b46b 9fb54f8
Author: bors bors@rust-lang.org
Date: Sun Mar 29 08:14:30 2015 +0000

and it compiles with no problem. So it does appear to be a recent bug.

[ghost]

Ah nvm. The problem wasn't introduced. I had compiled/tested with

make check-stage1-collections NO_REBUILD=1 NO_BENCH=1

However when I just do a full make, it fails on stage0. So it looks like this is a case of the older version of the compiler which builds stage0 not supporting it. I'll push a fix shortly.

[pnkfelix]

@bors r+ ac617b6 rollup

[bors]

⌛️ Testing commit ac617b6 with merge 47def3e...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-32-nopt-t, auto-win-32-opt, auto-win-64-nopt-t, auto-win-64-opt