Skip to content

/rust

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

permit `Drop` types in constants (tracking issue for RFC #1440) #33156

Closed
nikomatsakis opened this Issue Apr 22, 2016 · 18 comments

Comments

Assignees

@eddyb eddyb

Labels
B-RFC-implemented B-unstable C-tracking-issue T-lang final-comment-period
Projects
None yet
Milestone
No milestone
10 participants
@nikomatsakis @kornholi @brson @coder543 @SimonSapin @rfcbot @eddyb @aturon @nrc @Mark-Simulacrum
@nikomatsakis
Copy link
Contributor

nikomatsakis commented Apr 22, 2016 •
edited by eddyb

Tracking issue for rust-lang/rfcs#1440: "Allow Drop types in statics/const functions"

@nikomatsakis nikomatsakis added T-lang B-unstable labels Apr 22, 2016

@nikomatsakis nikomatsakis referenced this issue Apr 22, 2016

Merged

RFC - Allow Drop types in statics/const functions #1440

@eddyb eddyb self-assigned this Apr 25, 2016

@eddyb eddyb referenced this issue Apr 26, 2016

Merged

Implement constant support in MIR. #33130

bors added a commit that referenced this issue May 6, 2016

@bors
Auto merge of #33130 - eddyb:mir-const, r=nikomatsakis 
Implement constant support in MIR.

All of the intended features in `trans::consts` are now supported by `mir::constant`.
The implementation is considered a temporary measure until `miri` replaces it.

A `-Z orbit` bootstrap build will only translate LLVM IR from AST for `#[rustc_no_mir]` functions.

Furthermore, almost all checks of constant expressions have been moved to MIR.
In non-`const` functions, trees of temporaries are promoted, as per RFC 1414 (rvalue promotion).
Promotion before MIR borrowck would allow reasoning about promoted values' lifetimes.

The improved checking comes at the cost of four `[breaking-change]`s:
* repeat counts must contain a constant expression, e.g.:
`let arr = [0; { println!("foo"); 5 }];` used to be allowed (it behaved like `let arr = [0; 5];`)
* dereference of a reference to a `static` cannot be used in another `static`, e.g.:
`static X: [u8; 1] = [1]; static Y: u8 = (&X)[0];` was unintentionally allowed before
* the type of a `static` *must* be `Sync`, irrespective of the initializer, e.g.
`static FOO: *const T = &BAR;` worked as `&T` is `Sync`, but it shouldn't because `*const T` isn't
* a `static` cannot wrap `UnsafeCell` around a type that *may* need drop, e.g.
`static X: MakeSync<UnsafeCell<Option<String>>> = MakeSync(UnsafeCell::new(None));`
was previously allowed based on the fact `None` alone doesn't need drop, but in `UnsafeCell`
it can be later changed to `Some(String)` which *does* need dropping

The drop restrictions are relaxed by RFC 1440 (#33156), which is implemented, but feature-gated.
However, creating `UnsafeCell` from constants is unstable, so users can just enable the feature gate.
7134375

bors added a commit that referenced this issue May 7, 2016

@bors
Auto merge of #33130 - eddyb:mir-const, r=nikomatsakis 
Implement constant support in MIR.

All of the intended features in `trans::consts` are now supported by `mir::constant`.
The implementation is considered a temporary measure until `miri` replaces it.

A `-Z orbit` bootstrap build will only translate LLVM IR from AST for `#[rustc_no_mir]` functions.

Furthermore, almost all checks of constant expressions have been moved to MIR.
In non-`const` functions, trees of temporaries are promoted, as per RFC 1414 (rvalue promotion).
Promotion before MIR borrowck would allow reasoning about promoted values' lifetimes.

The improved checking comes at the cost of four `[breaking-change]`s:
* repeat counts must contain a constant expression, e.g.:
`let arr = [0; { println!("foo"); 5 }];` used to be allowed (it behaved like `let arr = [0; 5];`)
* dereference of a reference to a `static` cannot be used in another `static`, e.g.:
`static X: [u8; 1] = [1]; static Y: u8 = (&X)[0];` was unintentionally allowed before
* the type of a `static` *must* be `Sync`, irrespective of the initializer, e.g.
`static FOO: *const T = &BAR;` worked as `&T` is `Sync`, but it shouldn't because `*const T` isn't
* a `static` cannot wrap `UnsafeCell` around a type that *may* need drop, e.g.
`static X: MakeSync<UnsafeCell<Option<String>>> = MakeSync(UnsafeCell::new(None));`
was previously allowed based on the fact `None` alone doesn't need drop, but in `UnsafeCell`
it can be later changed to `Some(String)` which *does* need dropping

The drop restrictions are relaxed by RFC 1440 (#33156), which is implemented, but feature-gated.
However, creating `UnsafeCell` from constants is unstable, so users can just enable the feature gate.
ebf4761

bors added a commit that referenced this issue May 7, 2016

@bors
Auto merge of #33130 - eddyb:mir-const, r=nikomatsakis 
Implement constant support in MIR.

All of the intended features in `trans::consts` are now supported by `mir::constant`.
The implementation is considered a temporary measure until `miri` replaces it.

A `-Z orbit` bootstrap build will only translate LLVM IR from AST for `#[rustc_no_mir]` functions.

Furthermore, almost all checks of constant expressions have been moved to MIR.
In non-`const` functions, trees of temporaries are promoted, as per RFC 1414 (rvalue promotion).
Promotion before MIR borrowck would allow reasoning about promoted values' lifetimes.

The improved checking comes at the cost of four `[breaking-change]`s:
* repeat counts must contain a constant expression, e.g.:
`let arr = [0; { println!("foo"); 5 }];` used to be allowed (it behaved like `let arr = [0; 5];`)
* dereference of a reference to a `static` cannot be used in another `static`, e.g.:
`static X: [u8; 1] = [1]; static Y: u8 = (&X)[0];` was unintentionally allowed before
* the type of a `static` *must* be `Sync`, irrespective of the initializer, e.g.
`static FOO: *const T = &BAR;` worked as `&T` is `Sync`, but it shouldn't because `*const T` isn't
* a `static` cannot wrap `UnsafeCell` around a type that *may* need drop, e.g.
`static X: MakeSync<UnsafeCell<Option<String>>> = MakeSync(UnsafeCell::new(None));`
was previously allowed based on the fact `None` alone doesn't need drop, but in `UnsafeCell`
it can be later changed to `Some(String)` which *does* need dropping

The drop restrictions are relaxed by RFC 1440 (#33156), which is implemented, but feature-gated.
However, creating `UnsafeCell` from constants is unstable, so users can just enable the feature gate.
41f3d25

bors added a commit that referenced this issue May 7, 2016

@bors
Auto merge of #33130 - eddyb:mir-const, r=nikomatsakis 
Implement constant support in MIR.

All of the intended features in `trans::consts` are now supported by `mir::constant`.
The implementation is considered a temporary measure until `miri` replaces it.

A `-Z orbit` bootstrap build will only translate LLVM IR from AST for `#[rustc_no_mir]` functions.

Furthermore, almost all checks of constant expressions have been moved to MIR.
In non-`const` functions, trees of temporaries are promoted, as per RFC 1414 (rvalue promotion).
Promotion before MIR borrowck would allow reasoning about promoted values' lifetimes.

The improved checking comes at the cost of four `[breaking-change]`s:
* repeat counts must contain a constant expression, e.g.:
`let arr = [0; { println!("foo"); 5 }];` used to be allowed (it behaved like `let arr = [0; 5];`)
* dereference of a reference to a `static` cannot be used in another `static`, e.g.:
`static X: [u8; 1] = [1]; static Y: u8 = (&X)[0];` was unintentionally allowed before
* the type of a `static` *must* be `Sync`, irrespective of the initializer, e.g.
`static FOO: *const T = &BAR;` worked as `&T` is `Sync`, but it shouldn't because `*const T` isn't
* a `static` cannot wrap `UnsafeCell` around a type that *may* need drop, e.g.
`static X: MakeSync<UnsafeCell<Option<String>>> = MakeSync(UnsafeCell::new(None));`
was previously allowed based on the fact `None` alone doesn't need drop, but in `UnsafeCell`
it can be later changed to `Some(String)` which *does* need dropping

The drop restrictions are relaxed by RFC 1440 (#33156), which is implemented, but feature-gated.
However, creating `UnsafeCell` from constants is unstable, so users can just enable the feature gate.
45897b0

bors added a commit that referenced this issue May 7, 2016

@bors
Auto merge of #33130 - eddyb:mir-const, r=nikomatsakis 
Implement constant support in MIR.

All of the intended features in `trans::consts` are now supported by `mir::constant`.
The implementation is considered a temporary measure until `miri` replaces it.

A `-Z orbit` bootstrap build will only translate LLVM IR from AST for `#[rustc_no_mir]` functions.

Furthermore, almost all checks of constant expressions have been moved to MIR.
In non-`const` functions, trees of temporaries are promoted, as per RFC 1414 (rvalue promotion).
Promotion before MIR borrowck would allow reasoning about promoted values' lifetimes.

The improved checking comes at the cost of four `[breaking-change]`s:
* repeat counts must contain a constant expression, e.g.:
`let arr = [0; { println!("foo"); 5 }];` used to be allowed (it behaved like `let arr = [0; 5];`)
* dereference of a reference to a `static` cannot be used in another `static`, e.g.:
`static X: [u8; 1] = [1]; static Y: u8 = (&X)[0];` was unintentionally allowed before
* the type of a `static` *must* be `Sync`, irrespective of the initializer, e.g.
`static FOO: *const T = &BAR;` worked as `&T` is `Sync`, but it shouldn't because `*const T` isn't
* a `static` cannot wrap `UnsafeCell` around a type that *may* need drop, e.g.
`static X: MakeSync<UnsafeCell<Option<String>>> = MakeSync(UnsafeCell::new(None));`
was previously allowed based on the fact `None` alone doesn't need drop, but in `UnsafeCell`
it can be later changed to `Some(String)` which *does* need dropping

The drop restrictions are relaxed by RFC 1440 (#33156), which is implemented, but feature-gated.
However, creating `UnsafeCell` from constants is unstable, so users can just enable the feature gate.
6c7f924

bors added a commit that referenced this issue May 8, 2016

@bors
Auto merge of #33130 - eddyb:mir-const, r=nikomatsakis 
Implement constant support in MIR.

All of the intended features in `trans::consts` are now supported by `mir::constant`.
The implementation is considered a temporary measure until `miri` replaces it.

A `-Z orbit` bootstrap build will only translate LLVM IR from AST for `#[rustc_no_mir]` functions.

Furthermore, almost all checks of constant expressions have been moved to MIR.
In non-`const` functions, trees of temporaries are promoted, as per RFC 1414 (rvalue promotion).
Promotion before MIR borrowck would allow reasoning about promoted values' lifetimes.

The improved checking comes at the cost of four `[breaking-change]`s:
* repeat counts must contain a constant expression, e.g.:
`let arr = [0; { println!("foo"); 5 }];` used to be allowed (it behaved like `let arr = [0; 5];`)
* dereference of a reference to a `static` cannot be used in another `static`, e.g.:
`static X: [u8; 1] = [1]; static Y: u8 = (&X)[0];` was unintentionally allowed before
* the type of a `static` *must* be `Sync`, irrespective of the initializer, e.g.
`static FOO: *const T = &BAR;` worked as `&T` is `Sync`, but it shouldn't because `*const T` isn't
* a `static` cannot wrap `UnsafeCell` around a type that *may* need drop, e.g.
`static X: MakeSync<UnsafeCell<Option<String>>> = MakeSync(UnsafeCell::new(None));`
was previously allowed based on the fact `None` alone doesn't need drop, but in `UnsafeCell`
it can be later changed to `Some(String)` which *does* need dropping

The drop restrictions are relaxed by RFC 1440 (#33156), which is implemented, but feature-gated.
However, creating `UnsafeCell` from constants is unstable, so users can just enable the feature gate.
1ec2217

@indiv0 indiv0 referenced this issue May 14, 2016

Merged

Fix `lazy_static` Usage #260

@kornholi

This comment has been minimized.

Sign in to view
Copy link

kornholi commented Jun 3, 2016

Ran into an ICE: #34053

@nrc nrc added B-RFC-approved B-RFC-implemented and removed B-RFC-approved labels Aug 29, 2016

@Mark-Simulacrum Mark-Simulacrum referenced this issue Dec 22, 2016

Open

UnsafeCell allows types with destructors to end up in statics. #30667

@brson

This comment has been minimized.

Sign in to view
Copy link
Contributor

brson commented Jan 11, 2017

Is there anything holding up this feature? No activity.

This is used by Rocket.
@coder543

This comment has been minimized.

Sign in to view
Copy link

coder543 commented Feb 6, 2017

Bumping this as well. It seems like a good candidate for stabilization?
@SimonSapin

This comment has been minimized.

Sign in to view
Copy link
Contributor

SimonSapin commented Feb 26, 2017 •
edited

+1 for stabilization.

Servo has a hack to work around this: a separate type with no destructor for using a static phf map, and a conversion during lookup. (This is in a crate used by Firefox, which runs on stable Rust.) Stabilizing would allow removing this hack.
@nikomatsakis

This comment has been minimized.

Sign in to view
Copy link
Contributor Author

nikomatsakis commented Mar 2, 2017

I feel ok with stabilizing drop types in statics specifically.
@nikomatsakis

This comment has been minimized.

Sign in to view
Copy link
Contributor Author

nikomatsakis commented Mar 2, 2017

@rfcbot fcp merge

I propose that we stabilize this feature, which allows types that implement Drop to appear in static and const fn. It does not (yet) permit them in const initializers, though there is a pending RFC rust-lang/rfcs#1817 on that topic (which has a few complications).
@rfcbot

This comment has been minimized.

Sign in to view
Copy link

rfcbot commented Mar 2, 2017 •
edited by pnkfelix

Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged teams:

No concerns currently listed.

Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.
@eddyb

This comment has been minimized.

Sign in to view
Copy link
Member

eddyb commented Mar 2, 2017

@rfcbot fcp concern We can't stabilize this until we ban temporaries that "would drop" (see #40036).
@aturon

This comment has been minimized.

Sign in to view
Copy link
Member

aturon commented Mar 14, 2017

@rfcbot fcp cancel

I'm cancelling FCP due to @eddy's comment, just to get it cleared out of the queue. Let's revisit when #40036 is closed.
@rfcbot

This comment has been minimized.

Sign in to view
Copy link

rfcbot commented Mar 14, 2017

@aturon proposal cancelled.

@pnkfelix pnkfelix referenced this issue Mar 20, 2017

Merged

Amend #1440: allow `const` items to contain drop types. #1817

@SergioBenitez SergioBenitez referenced this issue May 19, 2017

Open

Compile with stable Rust #19

8 of 13 tasks complete
@brson

This comment has been minimized.

Sign in to view
Copy link
Contributor

brson commented May 22, 2017

No progress here lately. @eddyb what's the likelihood of fixing #40036 any time soon?

@Mark-Simulacrum Mark-Simulacrum added the C-tracking-issue label Jul 22, 2017

@eddyb

This comment has been minimized.

Sign in to view
Copy link
Member

eddyb commented Jul 25, 2017

I have a branch with the forwards compatibility checks for #40036, with no known stable code breakages, and one unstable intended regression (ironically, in @SergioBenitez's Rocket).
The catch is that it depends on rvalue promotion to be backwards compatible.
There was no reason to let this sit around this long, but I think we can move forward this release cycle.

Ryan1729 added a commit to Ryan1729/live-code-sdl2-opengl-2_1-template that referenced this issue Aug 10, 2017

@Ryan1729
use a hack to allow drawing a single string on top of everything else 
hack was necessary because `Drop` tyes are currently not allowed in statics.
see rust-lang/rust#33156

Signed-off-by: Ryan1729 <Ryan1729@gmail.com>
6eb8005

@eddyb eddyb changed the title permit `Drop` types in statics (tracking issue for RFC #1440) permit `Drop` types in constants (tracking issue for RFC #1440) Aug 28, 2017

@eddyb

This comment has been minimized.

Sign in to view
Copy link
Member

eddyb commented Aug 28, 2017

With rvalue promotion stabilized, #43932 produces no regressions and is waiting on review.
Once it's merged, we can implement the amendment RFC (for consts, including associated ones).
Do we need to delay stabilizing this feature, including the amendment, @rust-lang/lang?
Otherwise I'll propose to implement the amendment and stabilize it at once.
@aturon

This comment has been minimized.

Sign in to view
Copy link
Member

aturon commented Aug 28, 2017

@eddyb I think it's totally fine to stabilize the original feature at this point, but am slightly wary of stabilizing the amendment immediately upon implementation. OTOH, it's a little hard to imagine that we'll get much feedback on nightly about it.
@eddyb

This comment has been minimized.

Sign in to view
Copy link
Member

eddyb commented Aug 31, 2017

@rfcbot fcp merge

I propose that we implement the amendment and stabilize this feature now that the main blocker has been resolved - see #33156 (comment) also.
@rfcbot

This comment has been minimized.

Sign in to view
Copy link

rfcbot commented Aug 31, 2017 •
edited by withoutboats

Team member @eddyb has proposed to merge this. The next step is review by the rest of the tagged teams:

No concerns currently listed.

Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@rfcbot rfcbot added the proposed-final-comment-period label Aug 31, 2017

@eddyb eddyb referenced this issue Aug 31, 2017

Merged

Allow Drop types in const's too, with #![feature(drop_types_in_const)]. #44212

@rfcbot

This comment has been minimized.

Sign in to view
Copy link

rfcbot commented Sep 1, 2017

🔔 This is now entering its final comment period, as per the review above. 🔔

@rfcbot rfcbot added final-comment-period and removed proposed-final-comment-period labels Sep 1, 2017

bors added a commit that referenced this issue Sep 7, 2017

@bors
Auto merge of #44212 - eddyb:drop-const, r=nikomatsakis 
Allow Drop types in const's too, with #![feature(drop_types_in_const)].

Implements the remaining amendment, see #33156. cc @SergioBenitez

r? @nikomatsakis
Loading status checks…
af440b1

bors added a commit that referenced this issue Sep 7, 2017

@bors
Auto merge of #44212 - eddyb:drop-const, r=nikomatsakis 
Allow Drop types in const's too, with #![feature(drop_types_in_const)].

Implements the remaining amendment, see #33156. cc @SergioBenitez

r? @nikomatsakis
Loading status checks…
c760aa7

bors added a commit that referenced this issue Sep 7, 2017

@bors
Auto merge of #44212 - eddyb:drop-const, r=nikomatsakis 
Allow Drop types in const's too, with #![feature(drop_types_in_const)].

Implements the remaining amendment, see #33156. cc @SergioBenitez

r? @nikomatsakis
Loading status checks…
8d30e7d

bors added a commit that referenced this issue Sep 8, 2017

@bors
Auto merge of #44212 - eddyb:drop-const, r=nikomatsakis 
Allow Drop types in const's too, with #![feature(drop_types_in_const)].

Implements the remaining amendment, see #33156. cc @SergioBenitez

r? @nikomatsakis
Loading status checks…
2e2b1fe

bors added a commit that referenced this issue Sep 9, 2017

@bors
Auto merge of #44212 - eddyb:drop-const, r=nikomatsakis 
Allow Drop types in const's too, with #![feature(drop_types_in_const)].

Implements the remaining amendment, see #33156. cc @SergioBenitez

r? @nikomatsakis
Loading status checks…
18366f4

@eddyb eddyb referenced this issue Sep 9, 2017

Merged

Stabilize drop_types_in_const. #44456

@rfcbot

This comment has been minimized.

Sign in to view
Copy link

rfcbot commented Sep 11, 2017

The final comment period is now complete.

bors added a commit that referenced this issue Sep 13, 2017

@bors
Auto merge of #44456 - eddyb:stable-drop-const, r=nikomatsakis 
Stabilize drop_types_in_const.

Closes #33156, stabilizing the new, revised, rules, and improving the error message.

r? @nikomatsakis cc @SergioBenitez
Loading status checks…
7eefed3

@bors bors closed this in #44456 Sep 13, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.