Make some `Clone` impls `const` by lilasta · Pull Request #91804 · rust-lang/rust

lilasta · 2021-12-11T19:04:53Z

Tracking issue: #91805
Clone::clone_from and some impls (Option, Result) bounded on ~const Drop.

// core::clone
impl const Clone for INTEGER
impl const Clone for FLOAT
impl const Clone for bool
impl const Clone for char
impl const Clone for !
impl<T: ?Sized> const Clone for *const T
impl<T: ?Sized> const Clone for *mut T
impl<T: ?Sized> const Clone for &T

// core::option
impl<T> const Clone for Option<T>
where
    T: ~const Clone + ~const Drop

// core::result
impl<T, E> const Clone for Result<T, E>
where
    T: ~const Clone + ~const Drop,
    E: ~const Clone + ~const Drop,

// core::convert
impl const Clone for Infallible

// core::ptr
impl<T: ?Sized> const Clone for NonNull<T>
impl<T: ?Sized> const Clone for Unique<T>

rust-highfive · 2021-12-11T19:04:56Z

r? @joshtriplett

(rust-highfive has picked a reviewer for you, use r? to override)

camelid · 2022-01-25T20:37:35Z

r? @oli-obk maybe?

oli-obk · 2022-01-26T09:34:40Z

library/core/src/option.rs

+#[rustc_const_unstable(feature = "const_clone", issue = "91805")]
+impl<T> const Clone for Option<T>
+where
+    T: ~const Clone + ~const Drop,


Does this change the way rustdoc renders it?

Before:

After:

ah yea, there's a pending fix for the missing space, but the additional Drop bound is really confusing for users and we should probably figure out out story there (both for documentation and explanation) before we expose it

Will all such cases need to be explained in the future? It seems a bit hard... I think it would be nice if we could switch displaying of ~const (and ~const Drop) bound...

Yea, I'm unsure about ~const bounds in general, we should probably talk to the rustdoc team to figure out how it should display.

For ~const Drop I think we should just hide it from rustdoc. That bound is pretty much useless to see for anyone. We could potentially add a small symbol to the generic param that has a ~const Drop bound. Otherwise I fear that the useful bounds may get drowned out

T: ~const Drop seems to mean "T doesn't require non-const Drop to destruct the value", not "T implements ~const Drop". For example, primitive types don't implement const Drop but are destructible at compile-time. Anyway, the point is that this is mostly needed in code that destructs values at compile-time and is implemented using generics.

The determination seems to be implemented here:
https://github.com/rust-lang/rust/blob/master/compiler/rustc_const_eval/src/transform/check_consts/qualifs.rs#L140

T: ~const Drop seems to mean "T doesn't require non-const Drop to destruct the value"

I'm a bit confused about what you mean. Do you mean "T must be able to be Droped at compile-time"?

Yes. I'm sorry for confusing you.

What does the ~ mean? I thought ~const meant "maybe const" rather than "definitely const", but I may have misunderstood.

It means "const if whatever the bound is on is in a const context". So if it's on a generic param of a const fn, calling that const fn in a const item or other const context requires the generic param to implement the trait constly, in regular runtime code it just requires the trait to be implemented with no requirement about constness at all

oli-obk · 2022-03-09T12:58:29Z

This should be hidden from rustdoc now, and it doesn't introduce any new bounds that would not be hidden, so

@bors r+ rollup

bors · 2022-03-09T12:58:31Z

📌 Commit 6620244 has been approved by oli-obk

Make some `Clone` impls `const` Tracking issue: rust-lang#91805 `Clone::clone_from` and some impls (Option, Result) bounded on `~const Drop`. ```rust // core::clone impl const Clone for INTEGER impl const Clone for FLOAT impl const Clone for bool impl const Clone for char impl const Clone for ! impl<T: ?Sized> const Clone for *const T impl<T: ?Sized> const Clone for *mut T impl<T: ?Sized> const Clone for &T // core::option impl<T> const Clone for Option<T> where T: ~const Clone + ~const Drop // core::result impl<T, E> const Clone for Result<T, E> where T: ~const Clone + ~const Drop, E: ~const Clone + ~const Drop, // core::convert impl const Clone for Infallible // core::ptr impl<T: ?Sized> const Clone for NonNull<T> impl<T: ?Sized> const Clone for Unique<T> ```

…askrgr Rollup of 8 pull requests Successful merges: - rust-lang#91804 (Make some `Clone` impls `const`) - rust-lang#92541 (Mention intent of `From` trait in its docs) - rust-lang#93057 (Add Iterator::collect_into) - rust-lang#94739 (Suggest `if let`/`let_else` for refutable pat in `let`) - rust-lang#94754 (Warn users about `||` in let chain expressions) - rust-lang#94763 (Add documentation about lifetimes to thread::scope.) - rust-lang#94768 (Ignore `close_read_wakes_up` test on SGX platform) - rust-lang#94772 (Add miri to the well known conditional compilation names and values) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup

…st Clone` `Clone::clone_from` gained `#[default_method_body_is_const]` in [rust-lang/rust#91804][1]. n.b. `vec.rs` is shared by `r3_core` and `r3_kernel` (via a symbolic link), hence the lack of a scope in the commit message headline. [1]: rust-lang/rust#91804

rust-highfive assigned joshtriplett Dec 11, 2021

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 11, 2021

lilasta changed the title ~~Make Clone impls const~~ Make some Clone impls const Dec 11, 2021

lilasta mentioned this pull request Dec 11, 2021

Tracking Issue for const_clone #91805

Closed

3 tasks

Make some Clone impls const

6620244

apiraino added the T-libs Relevant to the library team, which will review and decide on the PR/issue. label Dec 14, 2021

rust-highfive assigned oli-obk and unassigned joshtriplett Jan 25, 2022

oli-obk reviewed Jan 26, 2022

View reviewed changes

oli-obk added S-blocked Status: Blocked on something else such as an RFC or other implementation work. and removed S-blocked Status: Blocked on something else such as an RFC or other implementation work. labels Mar 2, 2022

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 Mar 9, 2022

matthiaskrgr mentioned this pull request Mar 9, 2022

Rollup of 8 pull requests #94771

Closed

matthiaskrgr mentioned this pull request Mar 9, 2022

Rollup of 7 pull requests #94774

Closed

Dylan-DPC mentioned this pull request Mar 9, 2022

Rollup of 16 pull requests #94784

Closed

matthiaskrgr mentioned this pull request Mar 9, 2022

Rollup of 8 pull requests #94787

Merged

bors merged commit c025962 into rust-lang:master Mar 10, 2022

rustbot added this to the 1.61.0 milestone Mar 10, 2022

lilasta deleted the const_clone branch March 10, 2022 12:42

Uh oh!

Comments

Conversation

lilasta commented Dec 11, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rust-highfive commented Dec 11, 2021

Uh oh!

camelid commented Jan 25, 2022

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lilasta Jan 30, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

camelid Feb 3, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

oli-obk commented Mar 9, 2022

Uh oh!

bors commented Mar 9, 2022

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

lilasta commented Dec 11, 2021 •

edited

Loading

lilasta Jan 30, 2022 •

edited

Loading

camelid Feb 3, 2022 •

edited

Loading