Skip to content

Mark constructor of BinaryHeap as const fn #117316

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.

Sign up for GitHub

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

Merged
merged 1 commit into from
Oct 29, 2023
Merged

Mark constructor of BinaryHeap as const fn #117316

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 4 additions & 2 deletions library/alloc/src/collections/binary_heap/mod.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -434,8 +434,9 @@ impl<T: Ord> BinaryHeap<T> {
/// heap.push(4);
/// ```
#[stable(feature = "rust1", since = "1.0.0")]
#[rustc_const_unstable(feature = "const_binary_heap_constructor", issue = "112353")]
#[must_use]
pub fn new() -> BinaryHeap<T> {
pub const fn new() -> BinaryHeap<T> {
BinaryHeap { data: vec![] }
Copy link
Contributor

@oli-obk oli-obk Oct 29, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if you use Vec::new() here, then BinaryHeap::new can become const stable. vec![] goes through a code path that assumes it needs to allocate.

Copy link
Contributor Author

@Coekjan Coekjan Oct 29, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps I should have marked constification of new and new_in as different features, which may helps to stablize const new function.

Copy link
Contributor Author

@Coekjan Coekjan Oct 29, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

rust/library/alloc/src/macros.rs

Lines 42 to 57 in bbcc169

macro_rules! vec {
() => (
$crate::__rust_force_expr!($crate::vec::Vec::new())
);
($elem:expr; $n:expr) => (
$crate::__rust_force_expr!($crate::vec::from_elem($elem, $n))
);
($($x:expr),+ $(,)?) => (
$crate::__rust_force_expr!(<[_]>::into_vec(
// This rustc_box is not required, but it produces a dramatic improvement in compile
// time when constructing arrays with many elements.
#[rustc_box]
$crate::boxed::Box::new([$($x),+])
))
);
}

It seems that the macro vec![] (nothing filled within the bracket) just expands into Vec::new() without allocator.

Thus, constification of BinaryHeap::new is able to be stablized, if the new function does not share the mark rust_const_unstable(feature = "const_binary_heap_constructor") with BinaryHeap::new_in.

}

Expand Down Expand Up @@ -477,8 +478,9 @@ impl<T: Ord, A: Allocator> BinaryHeap<T, A> {
/// heap.push(4);
/// ```
#[unstable(feature = "allocator_api", issue = "32838")]
#[rustc_const_unstable(feature = "const_binary_heap_constructor", issue = "112353")]
#[must_use]
pub fn new_in(alloc: A) -> BinaryHeap<T, A> {
pub const fn new_in(alloc: A) -> BinaryHeap<T, A> {
BinaryHeap { data: Vec::new_in(alloc) }
}

Expand Down