Uh oh!
There was an error while loading. Please reload this page.
Treat repr(Rust) univariant fieldless enums as ZSTs - #49513
Merged
Conversation
rust-highfive
commented
Mar 30, 2018
Contributor
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @estebank (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
TimNN
commented
Mar 30, 2018
Contributor
Your PR failed on Travis. Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
eddyb
commented
Mar 30, 2018
Contributor
@alexcrichton@nikomatsakis Do you know whether we can just revert the previous decision here? |
alexcrichton
commented
Mar 30, 2018
Member
@eddyb I don't personally know of any instances of this in the wild, so it seems fine to me to land. I might prefer though to land it after the beta branches |
nox
commented
Mar 31, 2018
ContributorAuthor
The failure is that |
arielb1
reviewed
Mar 31, 2018
Contributor
There was a problem hiding this comment.
This makes the test no longer be a test of what it used to be testing. Could you add another variant before?
arielb1
reviewed
Mar 31, 2018
Contributor
There was a problem hiding this comment.
This makes the test no longer be a test of what it used to be testing. Could you add another variant B = 0 before A?
arielb1
reviewed
Mar 31, 2018
Contributor
There was a problem hiding this comment.
Afterwards, you should add a specific test for this.
TimNN
commented
Mar 31, 2018
Contributor
Your PR failed on Travis. Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
oli-obk
commented
Mar 31, 2018
Contributor
So apparently enumX{A = 0asisize}is now a ZST. I did not expect that, even though it makes sense. And it also explains the other failures we had before. |
oli-obkforce-pushed
the
univariant-fieldless-enum-as-zst
branch
from
March 31, 2018 21:06
a652155 to
4efed8fCompareoli-obk
commented
Mar 31, 2018
Contributor
I can implement this, but I'm getting slightly confused about the exact semantics we want here. Since enumX{A = 42asisize}is a zst, that means let x = X::A;is a zst value (so no value, just type system magic). This raises the question of how let y = x asisize;would get the Casting a println!("{}", y);
|
TimNN
commented
Mar 31, 2018
Contributor
Your PR failed on Travis. Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Member
@oli-obk The code for casting has access to the source and target types, right? If the source type is a single-variant fieldless enum, the result of the cast is just always the integer value of that single variant (i.e., it'll codegen a constant). Is there any problem with that? |
TimNN
commented
Mar 31, 2018
Contributor
Your PR failed on Travis. Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
eddyb
commented
Apr 1, 2018
Contributor
There might be missing code to get the right discriminant (42) from the variant_index (0). |
scottmcm
commented
Apr 1, 2018
Member
Hmm, there must be code somewhere for how |
TimNN
commented
Apr 1, 2018
Contributor
Your PR failed on Travis. Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
RalfJung
reviewed
Apr 1, 2018
Member
There was a problem hiding this comment.
These printlns are not actually tested for, are they? Could a ui test check them?
Contributor
There was a problem hiding this comment.
Those should simply be an assert
nox
commented
Apr 1, 2018
ContributorAuthor
@oli-obk I feel like my additional commit broke your newly-introduced test |
oli-obk
commented
Apr 1, 2018
Contributor
After your change the op isn't true anymore, right? Can you add some size_of assert tests? |
nox
commented
Apr 1, 2018
ContributorAuthor
If by "the op" you mean the fact that |
arielb1
commented
Apr 1, 2018
Contributor
Somewhere in run-pass. Could you find an existing test? |
arielb1
commented
Apr 1, 2018
Contributor
src/test/run-pass/type-sizes.rs |
Contributor
So... I'm confused as to what your latest commit changed. Why isn't the failing test not producing zsts anymore? |
ContributorAuthor
It still is, the following program prints two zeroes: use std::mem;fnmain(){enumE{V = 42asisize}let e = E::V;println!("{}", mem::size_of::<E>());println!("{}", e asisize);}The first one because E is still a ZST; the second one because there is a bug somewhere that I'm currently trying to fix. The change I reverted was an unrelated change that I shouldn't have committed in the first place, because it relates to the niche-filling optim which is orthogonal to what I'm trying to achieve here. Does that make sense to you @oli-obk? |
Contributor
Yes it does. Thanks for the explanation. I can fix the miri part after the runtime part works |
bors
commented
Apr 18, 2018
Collaborator
💔 Test failed - status-travis |
rust-highfive
commented
Apr 18, 2018
Contributor
Your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
1 similar comment
rust-highfive
commented
Apr 18, 2018
Contributor
Your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
bors
commented
Apr 24, 2018
Collaborator
☔ The latest upstream changes (presumably #49933) made this pull request unmergeable. Please resolve the merge conflicts. |
noxforce-pushed
the
univariant-fieldless-enum-as-zst
branch
from
April 25, 2018 08:33
98fb286 to
b11c244Comparebors
commented
Apr 26, 2018
Collaborator
☔ The latest upstream changes (presumably #50072) made this pull request unmergeable. Please resolve the merge conflicts. |
…#15747) This makes all those enums be represented the same way: ```rust enum A1 { B1 } enum A2 { B2 = 0 } enum A3 { B3, C3(!) } ```
I should rather properly fix debuginfo but I have no clue how to do that.
noxforce-pushed
the
univariant-fieldless-enum-as-zst
branch
from
April 26, 2018 14:22
b11c244 to
1c09977Compareeddyb
commented
Apr 26, 2018
Contributor
@bors r+ |
bors
commented
Apr 26, 2018
Collaborator
📌 Commit 1c09977 has been approved by |
bors
commented
Apr 26, 2018
Collaborator
bors added a commit
that referenced
this pull request
Apr 26, 2018
Treat repr(Rust) univariant fieldless enums as ZSTs
This makes all those enums be represented the same way:
```rust
enum A1 { B1 }
enum A2 { B2 = 0 }
enum A3 { B3, C3(!) }
```
Related to #15747.
Cc @rust-lang/wg-codegen @rust-lang/langbors
commented
Apr 26, 2018
Collaborator
☀️ Test successful - status-appveyor, status-travis |
kennytm added a commit
to kennytm/rust
that referenced
this pull request
May 3, 2018
Allow unaligned reads in constants fixesrust-lang#50356 introduced in rust-lang#49513
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
13 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This makes all those enums be represented the same way:
Related to #15747.
Cc @rust-lang/wg-codegen @rust-lang/lang