add try_reserve and try_reserve_exact to Vec

[Gankra]

Full rationale and proposal document coming Soon(TM), but I believe this is the API/impl that the gecko devs should use to solve their issues.

[Gankra]

CC @nnethercote @nox @pnkfelix @sfackler @aturon

[Gankra]

TODO:

• create tracking issue (and set unstable issue number)
• publish rationale doc
• benchmarks?

[rust-highfive]

r? @sfackler

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

@bors: try

[bors]

⌛ Trying commit 4d29038 with merge 1465398...

[bors]

☀️ Test successful - status-travis
State: approved= try=True

[glandium]

It seems like this only enables the oom handler from https://doc.rust-lang.org/alloc/oom/fn.set_oom_handler.html to be called, and it doesn't seem to allow to recover from the allocation failure.

So, say, for example, you have a browser trying to load a resource that would require to allocate a very large buffer of hundreds of megabytes, and there's not enough consecutive address space free to allocate those hundreds of megabytes. The allocator returns a failure. But then what?

[Gankra]

@glandium I don't understand what you're trying to say. What more could we possibly expose? The collection is left unmodified on failure, so you can do whatever you want.

There are a few patterns users of these APIs follow:

• Fail the current task (in much the same way as if input couldn't be parsed, or a connection failed, or whatever else), and hope the memory problems clear up (especially likely if the requested allocation was catastrophically large, such as from a malicious input)
• Take a slower and less memory-intensive path (e.g. move to in-place mergesort after failing to perform normal mergesort)
• Try to relieve memory pressure in the application (purge caches, garbage collect, etc)

[glandium]

So there are two things. The first is that I missed that try_reserve is to be called before each fallible operation on the vec, which is cumbersome, but enough to get started. The second is that this doesn't cover all the other types that enclose a vec internally (like HashMap).

[Gankra]

HashMap doesn't contain a Vec, but yes it should also have this API. As should VecDeque. Both of these types already have reserve methods so generalizing this to them should be simple. BTreeMap is more difficult, as fallible allocation fundamentally needs to be part of the element insertion process.

This PR is the first step towards developing our story on fallible allocation. It establishes the CollectionAllocErr type, and a basic idiom. This basic idiom is a decent 80/20 solution, as it covers almost every case with minimal API impact. Other collections, such as the fork of libcollections the Gecko devs will likely implement for FF57, can implement this idiom without diverging from the standard library.

[Gankra]

(still finishing up the longform rationale)

[alexcrichton]

I think you can make an AllocErr from a custom string, so is it worth having the distinction between these two errors at the API level? (e.g. do you think that these'll get matched on and dispatch to different behaviors?)

[alexcrichton]

And the second after I read this I see panics on capacity overflow and oom on allocation errors...

[Gankra]

Rationale: rust-lang/rfcs#2116

[aturon]

I'm going to close this pending RFC approval.

THANK YOU @gankro for pushing so hard on this topic! We'll try to move quickly on the RFC.