close
Skip to content

Support creating default Vec within a custom allocator#154990

Open
Nokel81 wants to merge 1 commit intorust-lang:mainfrom
Nokel81:vec-default-with-custom-allocator
Open

Support creating default Vec within a custom allocator#154990
Nokel81 wants to merge 1 commit intorust-lang:mainfrom
Nokel81:vec-default-with-custom-allocator

Conversation

@Nokel81
Copy link
Copy Markdown
Contributor

@Nokel81 Nokel81 commented Apr 8, 2026

This PR adds support for calling Default::default for some Vec<T, A> as long as the A also implements Default.

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Apr 8, 2026
@rustbot
Copy link
Copy Markdown
Collaborator

rustbot commented Apr 8, 2026

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

  • Owners of files modified in this PR: libs
  • libs expanded to 7 candidates
  • Random selection from Mark-Simulacrum, jhpratt

@Nokel81
Copy link
Copy Markdown
Contributor Author

Nokel81 commented Apr 8, 2026

@rustbot modify label: +I-libs-api-nominated

@rustbot rustbot added the I-libs-api-nominated Nominated for discussion during a libs-api team meeting. label Apr 8, 2026
@rust-log-analyzer
Copy link
Copy Markdown
Collaborator

The job pr-check-1 failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)
[RUSTC-TIMING] quick_error test:false 0.070
    Checking fnv v1.0.7
[RUSTC-TIMING] fnv test:false 0.062
    Checking rusty-fork v0.3.1
error[E0283]: type annotations needed for `Vec<NodeOrToken<SyntaxNode<RustLanguage>, SyntaxToken<...>>, _>`
   --> src/tools/rust-analyzer/crates/ide-db/src/syntax_helpers/tree_diff.rs:89:13
    |
 89 |         let mut look_ahead_scratch = Vec::default();
    |             ^^^^^^^^^^^^^^^^^^^^^^   --- type must be known at this point
    |
    = note: the type must implement `Allocator`
---
              std::sync::Arc<T, A>
note: required by a bound in `Vec`
   --> library/alloc/src/vec/mod.rs:438:78
    |
438 | pub struct Vec<T, #[unstable(feature = "allocator_api", issue = "32838")] A: Allocator = Global> {
    |                                                                              ^^^^^^^^^ required by this bound in `Vec`
    = note: the full name for the type has been written to '/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/i686-pc-windows-gnu/release/deps/ide_db-402cfb8f638e4fa4.long-type-7506825192990240553.txt'
    = note: consider using `--verbose` to print the full type name to the console
help: consider giving `look_ahead_scratch` an explicit type, where the type for type parameter `A` is specified
    |
 89 |         let mut look_ahead_scratch: Vec<_, A> = Vec::default();
    |                                   +++++++++++

[RUSTC-TIMING] build_script_build test:false 0.374
    Checking xshell v0.2.7
[RUSTC-TIMING] rusty_fork test:false 0.292

@bjorn3
Copy link
Copy Markdown
Member

bjorn3 commented Apr 8, 2026

This breaks type inference unfortunately.

@Nokel81
Copy link
Copy Markdown
Contributor Author

Nokel81 commented Apr 9, 2026

This breaks type inference unfortunately.

Is that because of the lack of defaults within impl blocks? Should I switch to using a form of specialization?

@bjorn3
Copy link
Copy Markdown
Member

bjorn3 commented Apr 9, 2026

Type inference unfortunately ignores defaults entirely. This is also why for example HashMap::new() doesn't allow picking a hasher. I don't see how specialization can help here at all.

@Nokel81
Copy link
Copy Markdown
Contributor Author

Nokel81 commented Apr 9, 2026

Type inference unfortunately ignores defaults entirely. This is also why for example HashMap::new() doesn't allow picking a hasher. I don't see how specialization can help here at all.

From reading the docs I was thinking that it would be possible to mark impl <T> const Default for Vec<T> (or maybe for Vec<T, Global> since that is what it means) as the "default" version for type inference and then still have impl <T, A: Allocator + [const] Default> const Default for Vec<T, A> as an impl that exists but is ignored when doing type inference.

@bjorn3
Copy link
Copy Markdown
Member

bjorn3 commented Apr 9, 2026

I don't believe that is possible, but I did be happy to be proven wrong.

@Mark-Simulacrum
Copy link
Copy Markdown
Member

@rustbot author

Feel free to mark as waiting on review if you find a solution (I don't have the bandwidth to help search for one unfortunately). Maybe asking on Zulip is a reasonable starting point.

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 11, 2026
@rustbot
Copy link
Copy Markdown
Collaborator

rustbot commented Apr 11, 2026

Reminder, once the PR becomes ready for a review, use @rustbot ready.

@nia-e
Copy link
Copy Markdown
Member

nia-e commented Apr 15, 2026

Per discussion in the last @rust-lang/libs-api meeting, this would be nice to add but we don't think it's possible without extensive breakage due to how inference currently works. This will be brought up with the edition team as there may be some way to allow this - it would certainly be useful! - but unfortunately this PR is going to be blocked on that at a minimum. Thanks ^^

@nia-e nia-e added S-blocked Status: Blocked on something else such as an RFC or other implementation work. and removed I-libs-api-nominated Nominated for discussion during a libs-api team meeting. labels Apr 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-blocked Status: Blocked on something else such as an RFC or other implementation work. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants