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

[nikomatsakis]

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

• [x] Implement amendment RFC
• [ ] [Improve error message](https://github.com/rust-lang/rust/pull/44212#discussion_r136288924)

[kornholi]

Ran into an ICE: #34053

[brson]

Is there anything holding up this feature? No activity.

This is used by Rocket.

[coder543]

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

[SimonSapin]

+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]

I feel ok with stabilizing drop types in statics specifically.

[nikomatsakis]

@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 https://github.com/rust-lang/rfcs/pull/1817 on that topic (which has a few complications).

[rfcbot]

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

• [ ] @aturon
• [ ] @eddyb
• [x] @nikomatsakis
• [x] @nrc
• [x] @pnkfelix
• [ ] @withoutboats

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]

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

[aturon]

@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 https://github.com/rust-lang/rust/issues/40036 is closed.

[rfcbot]

@aturon proposal cancelled.

[brson]

No progress here lately. @eddyb what's the likelihood of fixing https://github.com/rust-lang/rust/issues/40036 any time soon?

[eddyb]

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.

[eddyb]

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]

@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]

@rfcbot fcp merge

I propose that we implement the amendment and stabilize this feature now that the main blocker has been resolved - see https://github.com/rust-lang/rust/issues/33156#issuecomment-325289795 also.

[rfcbot]

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

• [x] @aturon
• [x] @eddyb
• [x] @nikomatsakis
• [x] @nrc
• [x] @pnkfelix
• [x] @withoutboats

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]

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

[rfcbot]

The final comment period is now complete.