Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add guarantee that Vec::default() does not alloc #100872

Merged
merged 1 commit into from
Aug 22, 2022

Conversation

JanBeh
Copy link
Contributor

@JanBeh JanBeh commented Aug 22, 2022

Currently Vec::new() is guaranteed to not allocate until elements are pushed onto the Vec, but such a guarantee is missing for Vec's implementation of Default::default.

This adds such a guarantee for Vec::default() to the API reference.

See also this discussion on URLO.

Currently `Vec::new()` is guaranteed to not allocate until elements are
pushed onto the `Vec`, but such a guarantee is missing for `Vec`'s
implementation of `Default::default`. This adds such a guarantee for
`Vec::default()` to the API reference.
@rustbot rustbot added the T-libs Relevant to the library team, which will review and decide on the PR/issue. label Aug 22, 2022
@rust-highfive
Copy link
Collaborator

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

Please see the contribution instructions for more information.

@rustbot
Copy link
Collaborator

rustbot commented Aug 22, 2022

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

  • Stabilizing library features
  • Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
  • Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
  • Changing public documentation in ways that create new stability guarantees
  • Changing observable runtime behavior of library APIs

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 22, 2022
@JanBeh
Copy link
Contributor Author

JanBeh commented Aug 22, 2022

@rustbot label +T-libs-api -T-libs

@rustbot rustbot added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. and removed T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Aug 22, 2022
@fee1-dead
Copy link
Member

fee1-dead commented Aug 22, 2022

LGTM! Thanks for the PR. I am going to approve this (even though I am a compiler contributor) because I don't believe that such a guarantee would be unwanted as it would be a performance regression if it actually allocated.

@bors r+ rollup=always

@bors
Copy link
Contributor

bors commented Aug 22, 2022

📌 Commit 0227b71 has been approved by fee1-dead

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 22, 2022
@CryZe
Copy link
Contributor

CryZe commented Aug 22, 2022

Wouldn't it maybe make more sense to just guarantee that it always matches Vec::new()?

@JanBeh
Copy link
Contributor Author

JanBeh commented Aug 22, 2022

Wouldn't it maybe make more sense to just guarantee that it always matches Vec::new()?

I considered that too. It's a slightly stronger guarantee and not sure if it's needed. Maybe Vec::default() and Vec::new() could differ in some other way in future (though I can't think of any right now), apart from the latter being a const fn.

Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Aug 22, 2022
…=fee1-dead

Add guarantee that Vec::default() does not alloc

Currently `Vec::new()` is guaranteed to not allocate until elements are pushed onto the `Vec`, but such a guarantee is missing for `Vec`'s implementation of `Default::default`.

This adds such a guarantee for `Vec::default()` to the API reference.

See also [this discussion on URLO](https://users.rust-lang.org/t/guarantee-that-vec-default-does-not-allocate/79903).
bors added a commit to rust-lang-ci/rust that referenced this pull request Aug 22, 2022
Rollup of 8 pull requests

Successful merges:

 - rust-lang#98200 (Expand potential inner `Or` pattern for THIR)
 - rust-lang#99770 (Make some const prop mir-opt tests `unit-test`s)
 - rust-lang#99957 (Rework Ipv6Addr::is_global to check for global reachability rather than global scope - rebase)
 - rust-lang#100331 (Guarantee `try_reserve` preserves the contents on error)
 - rust-lang#100336 (Fix two const_trait_impl issues)
 - rust-lang#100713 (Convert diagnostics in parser/expr to SessionDiagnostic)
 - rust-lang#100820 (Use pointer `is_aligned*` methods)
 - rust-lang#100872 (Add guarantee that Vec::default() does not alloc)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@scottmcm
Copy link
Member

@rust-lang/libs-api I'm confident this is uncontroversial, but technically it's a new guarantee. Are you fine with this going in via just an r+, or do you want an FCP too?

@dtolnay
Copy link
Member

dtolnay commented Aug 22, 2022

This is fine without FCP, Vec::new already guarantees the same.

@bors bors merged commit 4ed8fa4 into rust-lang:master Aug 22, 2022
@rustbot rustbot added this to the 1.65.0 milestone Aug 22, 2022
@JanBeh JanBeh deleted the PR_vec_default_alloc_doc branch October 4, 2022 07:37
@JanBeh JanBeh restored the PR_vec_default_alloc_doc branch October 4, 2022 07:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants