Uh oh!
There was an error while loading. Please reload this page.
Fallible allocation - #48648
Conversation
rust-highfive
commented
Mar 1, 2018
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Kimundi (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. Due to 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 the contribution instructions for more information. |
snf
commented
Mar 3, 2018
I'm thinking if this should be behind a feature gate or not given the RFC was already approved. @Kimundi any idea? |
There was a problem hiding this comment.
Looks good!
Got confused by feature gates for new language features there. All new APIs should land as unstable, which automatically gives them the feature gate as written in the unstable attribute. So no extra work is needed, but marking it as a stable directly would be wrong. :)
There was a problem hiding this comment.
You turn a unwrap() into a return with CollectionAllocErr::CapacityOverflow here, which I think technically changes the behaviour (or at least the panic message). Is this just a bugfix because this is also technically a capacity overflow?
There was a problem hiding this comment.
In my understanding, if bucket allocation size cannot be calculated, it's a sign of capacity overflow. I don't think there is a regression risk here because the chances of hitting this case are probably very small. There are 2 things that will change here (1) non try_xxxx methods will have a different panic message (empty vs "capacity overflow") (2) the behaviour might change when oom=panic/abort is introduced.
There was a problem hiding this comment.
This needs to be the error message that the compiler actually outputs. use of unstable library feature "try_reserve" [...] or something like it.
There was a problem hiding this comment.
This should also reflect the error gotten from a unstable library feature.
snf
commented
Mar 3, 2018
I think this is all we want to do in this PR, I will create a separate one for |
Kimundi
commented
Mar 4, 2018
Seems there are still some import issues in the tests. |
snf
commented
Mar 7, 2018
r? @Kimundi . Thanks and sorry for all the messed up commits!, I will squash them after your review. |
Kimundi
commented
Mar 8, 2018
Weird that that failed the tests again... But yeah, feel free to squash :) |
snf
commented
Mar 8, 2018
Ok, I'm squashing the changes into one |
Done :). r? @Kimundi |
Kimundi
commented
Mar 8, 2018
@bors r+ |
bors
commented
Mar 8, 2018
📌 Commit 69c67d6 has been approved by |
bors
commented
Mar 9, 2018
⌛ Testing commit 69c67d637065063979405eb6e9a6d2db11159b8a with merge e1bda06a39850023925b8d72aabdc7a56ae13145... |
bors
commented
Mar 9, 2018
💔 Test failed - status-travis |
kennytm
commented
Mar 9, 2018
Cannot run |
kennytm
commented
Mar 14, 2018
@bors retry 3 hour timeout |
bors
commented
Mar 14, 2018
⌛ Testing commit d4e400407a1c231fcf7f90b020b0e73411a5baec with merge 6319df5ff2bf0c4ef9fb8f95b5c2eae3f237cd90... |
bors
commented
Mar 14, 2018
💔 Test failed - status-travis |
kennytm
commented
Mar 14, 2018
Recent UI test changes again has broken UI tests 😠. Please rebase and update |
snf
commented
Mar 14, 2018
kennytm
commented
Mar 14, 2018
@bors r=Kimundi |
bors
commented
Mar 14, 2018
📌 Commit 06057d9 has been approved by |
bors
commented
Mar 15, 2018
bors
commented
Mar 15, 2018
☀️ Test successful - status-appveyor, status-travis |
staktrace
commented
Mar 16, 2018
@snf@Kimundi Is it expected that this PR causes build breakage for some crates? For example mp4parse-rust seems to have stopped building in nightly rust, see https://bugzilla.mozilla.org/show_bug.cgi?id=1446538 |
snf
commented
Mar 16, 2018
@staktrace it's because of the conflicting names. I see that Mike commented that #48552 will fix it (and future breakages). |
staktrace
commented
Mar 17, 2018
@snf I don't have any objections but I'm also not the decision maker on this, I just happened to run into the build failure first. Maybe coordinate with the mp4parse-rust owners? |
Implementing RFC#2116 Fallible Allocation .
Work in progress. Initially adding @gankro's try_reserve for Vec.