Disallow Unsized Enums #37111
Disallow Unsized Enums #37111
Conversation
|
(rust_highfive has picked a reviewer for you, use r? to override) |
|
Hmm. So this is intended to work -- but I agree that it'd be better to give a clean error, short of making it work. Probably this would require a crater run to get some idea. |
|
cc @rust-lang/compiler @rust-lang/lang and @eddyb in particular =) This PR proposes to remove the ability for an enum to be unsized. They were intended to support this, but it was never fuly implemented, and the compiler currently ICEs if you really try to do anything. There is some backwards compatbility risk here, but it's pretty minor: you have to have enums that are potentially unsized but not used as such, I think. I'll try to kick off a crater run to get more data. I think I'm in favor of making them a hard error (to fix the ICEs) but opening an issue to implement the support properly. |
|
How difficult would it be to fix unsized enums? Is there design work to be done there or does it just need the implementation finished off? |
|
@nrc I don't think anything about them was ever specified, and I'd expect a RFC or at least ammendments. |
Can you say a bit more here? Off the top of my head I'm not sure what complications you are imagining would require amending RFCs and the like. |
|
@nikomatsakis There are no defined semantics. Which cases are allowed? One maybe-unsized variant? Potentially all of them? Does the pointer metadata behave as an union tagged by the enum itself? I suppose If we can agree on something and we can implement it by reusing univariant functionality in most places (as opposed to needing a lot of special logic), then I'm okay with just a RFC-less FCP. |
|
Started crater run from a29c49f to c5483ff3b9fb8b5fdb633707b3e38c66c83ddae6. |
|
Crater results: https://gist.github.com/13d56401d4ceee692d4ad9374c8d3600 6540 crates tested: 4832 working / 1648 broken / 6 regressed / 0 fixed / 54 unknown.
UPDATE: They all appear to be false positives. |
nikomatsakis
added
the
T-lang
|
EDIT I should have waited. |
|
Appears to be no regressions. I'm inclined to think we should just make this an error for now. I don't know that I think that an RFC is necessarily required to implement these changes, but it couldn't hurt in any case -- and ICEing is no good. @rfcbot fcp merge |
|
@eddyb I think it's all false, no? Though we could try (and perhaps should) testing those crates by hand. |
|
Team member nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged teams: No concerns currently listed. See this document for info about what commands tagged team members can give me. |
|
Great! Then I'll see about updating / adding tests in the next few days. |
|
I could successfully build all listed "regressions" with a local stage 1 of c5483ff3b9fb8b5fdb633707b3e38c66c83ddae6. |
|
I have adapted and added the test cases. |
| @@ -8,6 +8,8 @@ | |||
| // option. This file may not be copied, modified, or distributed | |||
| // except according to those terms. | |||
|
|
|||
| // ignore-test the unsized enum no longer compiles | |||
There was a problem hiding this comment.
I have ignored this test for now, but it has effectively become useless and could be deleted but I'm unsure what the policy is in this case.
|
@rfcbot reviewed Seems like making this an error is the correct thing to do for now. |
|
All relevant subteam members have reviewed. No concerns remain. |
|
@bors r+ |
|
📌 Commit db03257 has been approved by |
|
thanks tim On Wed, Oct 19, 2016 at 01:40:23PM -0700, Tim Neumann wrote:
|
Disallow Unsized Enums Fixes #16812. This PR is a potential fix for #16812, an issue which is reported [again](#36801) and [again](#36975), with over a dozen duplicates by now. This PR is mainly meant to promoted discussion about the issue and the correct way to fix it. This is a [breaking-change] since the error is now reported during wfchecking, so that even the definition of a (potentially) unsized enum will cause an error (whereas it would previously cause an ICE at trans time if the enum was used in an unsized manner).
brson
added
the
relnotes
Fixes #16812.
This PR is a potential fix for #16812, an issue which is reported again and again, with over a dozen duplicates by now.
This PR is mainly meant to promoted discussion about the issue and the correct way to fix it.
This is a [breaking-change] since the error is now reported during wfchecking, so that even the definition of a (potentially) unsized enum will cause an error (whereas it would previously cause an ICE at trans time if the enum was used in an unsized manner).