permit Drop types in constants (tracking issue for RFC #1440)
#33156
Comments
nikomatsakis
added
T-lang
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.
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.
|
Ran into an ICE: #34053 |
nrc
added
B-RFC-approved
|
Is there anything holding up this feature? No activity. This is used by Rocket. |
|
Bumping this as well. It seems like a good candidate for stabilization? |
|
+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. |
|
I feel ok with stabilizing drop types in statics specifically. |
|
@rfcbot fcp merge I propose that we stabilize this feature, which allows types that implement |
|
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. |
|
@aturon proposal cancelled. |
Mark-Simulacrum
added
the
C-tracking-issue
|
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). |
hack was necessary because `Drop` tyes are currently not allowed in statics. see rust-lang/rust#33156 Signed-off-by: Ryan1729 <[email protected]>
eddyb
changed the title
Drop types in statics (tracking issue for RFC #1440)Drop types in constants (tracking issue for RFC #1440)
|
With rvalue promotion stabilized, #43932 produces no regressions and is waiting on review. |
|
@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. |
|
@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. |
|
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
added
the
proposed-final-comment-period
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
rfcbot
added
final-comment-period
Allow Drop types in const's too, with #![feature(drop_types_in_const)]. Implements the remaining amendment, see #33156. cc @SergioBenitez 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
|
The final comment period is now complete. |
Stabilize drop_types_in_const. Closes #33156, stabilizing the new, revised, rules, and improving the error message. r? @nikomatsakis cc @SergioBenitez
Tracking issue for rust-lang/rfcs#1440: "Allow Drop types in statics/const functions"
The text was updated successfully, but these errors were encountered: