Preliminary support for unions added. #63
Conversation
This file contains 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
FYI, |
Apart from a couple of obvious bug fixes, this focuses on initialization
for unions. The previous initialization code had been designed with only struct
and arrays in mind, so some pretty deep changes had to be made.
* the data type `Initializer` now has three constructors for regular scalar
initializers, aggregate initializers (arrays and structs), and union
initializers. Might want to think about naming `Scalar` differently (see
section 6.2.5 point 21).
* `Initializer` is no longer a `Monoid`, since we can't make a `mempty`
without knowing the type we are initializing. Instead, it is a `Semigroup`,
with some combinations not valid. This means that either we will need
to enforce `base >= 4.9` or `semigroups`.
To the best of my current knowledge and testing, this accurately and completely
implements initialization of unions as per C99.
|
This build fails because one of the big changes that comes with this last commit (that adds what I think is complete support for union initialization) is that Personally I am in favour of the latter (if we are generating rust that only compiles on rust nightly, it seems fairly reasonably to say we run on GHC 8.0), but I'll leave the choice up to you. |
Add support for incomplete unions in the context of: * completing them * performing member access on them * zero initializing them Also added missing case in `Eq CType` for unions.
|
@harpocrates Conflicting files |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 is really far from complete, but it starts addressing #22 by filling in everything straightforward. Here are the issues AFAICT
We cannot yet derive
CopyandClonefor unions, but support for that is pending (incredibly fast given how recent an addition unions are!).We'll need to add
#![feature(untagged_unions)]to the top of files (I don't think we currently have anything to do this - if we don't it'd be worth it to make it good).The can of worms that was struct initialization needs to be reopened. I'll take a look at the C99 spec. I'm hoping that when there are multiple (named) initializers in the initializer list for a union in C99, we simply ignore all except the last one (even if the previous ones are bigger), and at least clang seems to agree... I'm also hoping that the rust unions are also initialized with an extra empty space zeroed out. If all that works out as expected, I'll still need to find a nice way of expressing union based initializers - something like
Is there anything else I'm missing here? I think there is something to do with incomplete types that you did for structs that also applies to unions. I'm thinking of this...