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

Stabilize Vec::new and String::new as const fns #64028

Merged
merged 2 commits into from
Sep 16, 2019
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
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
2 changes: 1 addition & 1 deletion src/liballoc/lib.rs
Original file line number Diff line number Diff line change
Expand Up @@ -117,7 +117,7 @@
#![feature(allocator_internals)]
#![feature(on_unimplemented)]
#![feature(rustc_const_unstable)]
#![feature(const_vec_new)]
#![cfg_attr(bootstrap, feature(const_vec_new))]
#![feature(slice_partition_dedup)]
#![feature(maybe_uninit_extra, maybe_uninit_slice)]
#![feature(alloc_layout_extra)]
Expand Down
27 changes: 26 additions & 1 deletion src/liballoc/raw_vec.rs
Original file line number Diff line number Diff line change
Expand Up @@ -113,13 +113,38 @@ impl<T, A: Alloc> RawVec<T, A> {
}

impl<T> RawVec<T, Global> {
/// HACK(Centril): This exists because `#[unstable]` `const fn`s needn't conform
/// to `min_const_fn` and so they cannot be called in `min_const_fn`s either.
///
/// If you change `RawVec<T>::new` or dependencies, please take care to not
/// introduce anything that would truly violate `min_const_fn`.
///
/// NOTE: We could avoid this hack and check conformance with some
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm pretty unhappy about this hack since I think carries the risk that we might stabilize things we don't want in const eval inadvertently and I have WIP more principled solution in https://github.com/Centril/rust/commits/stabilize-vec-new-const which I think we should seriously consider instead (but which can change into after this PR if necessary).

/// `#[rustc_force_min_const_fn]` attribute which requires conformance
/// with `min_const_fn` but does not necessarily allow calling it in
/// `stable(...) const fn` / user code not enabling `foo` when
/// `#[rustc_const_unstable(feature = "foo", ..)]` is present.
pub const NEW: Self = Self::new();

/// Creates the biggest possible `RawVec` (on the system heap)
/// without allocating. If `T` has positive size, then this makes a
/// `RawVec` with capacity `0`. If `T` is zero-sized, then it makes a
/// `RawVec` with capacity `usize::MAX`. Useful for implementing
/// delayed allocation.
pub const fn new() -> Self {
Self::new_in(Global)
// FIXME(Centril): Reintegrate this with `fn new_in` when we can.

// `!0` is `usize::MAX`. This branch should be stripped at compile time.
// FIXME(mark-i-m): use this line when `if`s are allowed in `const`:
//let cap = if mem::size_of::<T>() == 0 { !0 } else { 0 };

// `Unique::empty()` doubles as "unallocated" and "zero-sized allocation".
RawVec {
ptr: Unique::empty(),
// FIXME(mark-i-m): use `cap` when ifs are allowed in const
cap: [0, !0][(mem::size_of::<T>() == 0) as usize],
a: Global,
}
Copy link
Member

Choose a reason for hiding this comment

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

@ecstatic-morse @oli-obk are you keeping a list somewhere for all the awful hacks we have in libstd to work around const qualif limitations? This would be another one (there's also #63786).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Maybe we should have a special string for "const related awful hack"? FIXME(awful_const_hack) :D

We can make an issue also...

Copy link
Contributor

@ecstatic-morse ecstatic-morse Sep 16, 2019

Choose a reason for hiding this comment

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

We could also just tag PRs like this as const-workaround-if on GitHub, and someone can go through at the tagged PRs once the required operations are allowed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If we're going with a label, I'd make it a bit more general: const-hack.

Copy link
Contributor

@ecstatic-morse ecstatic-morse Sep 16, 2019

Choose a reason for hiding this comment

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

Presumably there could be a const-hack-loop and const-hack-mut-ref if anyone gets really frisky.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@ecstatic-morse I was wondering if we couldn't use one label for all of them?

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't care so much. I thought it would be easier to go back and remove the labels if we know exactly which limitation is being worked around, but the absence of conditionals is probably the only thing that can be circumvented with these kinds of hacks.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added a const-hack label. Please let me know if there are some PRs I missed.

Copy link
Contributor

Choose a reason for hiding this comment

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

I have a todo entry for reviewing all const fns after we get loops and conditions, I'm certain we'll miss some by whitelisting what to check

Copy link
Member

Choose a reason for hiding this comment

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

@Centril thanks!

@oli-obk Let's just go through the tag then after you are done with that review, to double-check.

}

/// Creates a `RawVec` (on the system heap) with exactly the
Expand Down
2 changes: 1 addition & 1 deletion src/liballoc/string.rs
Original file line number Diff line number Diff line change
Expand Up @@ -369,7 +369,7 @@ impl String {
/// ```
#[inline]
#[stable(feature = "rust1", since = "1.0.0")]
#[rustc_const_unstable(feature = "const_string_new")]
#[cfg_attr(bootstrap, rustc_const_unstable(feature = "const_string_new"))]
pub const fn new() -> String {
String { vec: Vec::new() }
}
Expand Down
4 changes: 2 additions & 2 deletions src/liballoc/vec.rs
Original file line number Diff line number Diff line change
Expand Up @@ -314,10 +314,10 @@ impl<T> Vec<T> {
/// ```
#[inline]
#[stable(feature = "rust1", since = "1.0.0")]
#[rustc_const_unstable(feature = "const_vec_new")]
#[cfg_attr(bootstrap, rustc_const_unstable(feature = "const_vec_new"))]
pub const fn new() -> Vec<T> {
Vec {
buf: RawVec::new(),
buf: RawVec::NEW,
len: 0,
}
}
Expand Down
8 changes: 2 additions & 6 deletions src/test/ui/collections-const-new.rs
Original file line number Diff line number Diff line change
@@ -1,15 +1,11 @@
// run-pass
// check-pass

#![allow(dead_code)]
// Test several functions can be used for constants
// 1. Vec::new()
// 2. String::new()

#![feature(const_vec_new)]
#![feature(const_string_new)]

const MY_VEC: Vec<usize> = Vec::new();

const MY_STRING: String = String::new();

pub fn main() {}
fn main() {}
Original file line number Diff line number Diff line change
Expand Up @@ -14,8 +14,9 @@ trait Bar<T, U: Foo<T>> {
impl Foo<u32> for () {
const X: u32 = 42;
}

impl Foo<Vec<u32>> for String {
const X: Vec<u32> = Vec::new(); //~ ERROR not yet stable as a const fn
const X: Vec<u32> = Vec::new();
}

impl Bar<u32, ()> for () {}
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -4,13 +4,5 @@ error[E0493]: destructors cannot be evaluated at compile-time
LL | const F: u32 = (U::X, 42).1;
| ^^^^^^^^^^ constants cannot evaluate destructors

error: `std::vec::Vec::<T>::new` is not yet stable as a const fn
--> $DIR/feature-gate-unleash_the_miri_inside_of_you.rs:18:25
|
LL | const X: Vec<u32> = Vec::new();
| ^^^^^^^^^^
|
= help: add `#![feature(const_vec_new)]` to the crate attributes to enable

error: aborting due to 2 previous errors
error: aborting due to previous error