Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

#

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Jump to bottom

Univariant enums cannot have repr set #10292

Closed
sp3d opened this issue Nov 5, 2013 · 5 comments
Closed

Univariant enums cannot have repr set #10292

sp3d opened this issue Nov 5, 2013 · 5 comments
Labels
A-FFI Area: Foreign function interface (FFI) P-medium Medium priority

Comments

@sp3d
Copy link
Contributor

sp3d commented Nov 5, 2013

In writing bindings for C libraries which feature enums in their API, single-variant enums can and do occur. However, binding these by generating a matching Rust enum with only one variant is not currently possible, as rustc gives
error: unsupported representation for univariant enum
on code like

#[repr(C)]
enum Foo
{
    Bar,
    //Dummy,
}

Currently this can be worked-around by adding a dummy variant as shown, but that shouldn't be necessary as it requires handling in consumer code, e.g. matches.

CC @jld who added the very very useful ability to use #[repr(C)] in the first place. :)
@emberian
Copy link
Member

The bug is that univariant enums are allowed no representation whatsoever, they seem to be forced to 1-byte. (Updating issue title to reflect this)

@emberian
Copy link
Member

ping @jld

@emberian
Copy link
Member

Nominating, seems important for FFI. Is backwards compatible, though.

@alexcrichton alexcrichton mentioned this issue Feb 18, 2014
Closed
@pnkfelix
Copy link
Member

Assigning P-high, not a 1.0 issue.

@simnalamburt
Copy link
Contributor

CC Me

@simnalamburt simnalamburt mentioned this issue Feb 18, 2015
Closed
@bluss bluss mentioned this issue May 20, 2015
Closed
@arielb1 arielb1 added A-FFI Area: Foreign function interface (FFI) and removed I-wrong labels Jun 29, 2015
@msiglreith msiglreith mentioned this issue Aug 22, 2015
Merged
@nikomatsakis nikomatsakis mentioned this issue Nov 4, 2015
Closed
@stepancheg stepancheg mentioned this issue Jan 27, 2016
Merged
stepancheg added a commit to stepancheg/rust that referenced this issue Jan 27, 2016
@stepancheg
Allow #[repr(i32)] for univariant enum
641267e 
```
#[repr(i32)]
enum Univariant {
    X = 17
}
```

Fixes rust-lang#10292
bors added a commit that referenced this issue Feb 1, 2016
@bors
Auto merge of #31232 - stepancheg:enum-univariant, r=nrc
14dc9fc 
```
enum Univariant {
    X = 17
}
```

Fixes #10292
@azasypkin azasypkin mentioned this issue Apr 24, 2016
Closed
flip1995 pushed a commit to flip1995/rust that referenced this issue Feb 10, 2023
@bors
Auto merge of rust-lang#10292 - xFrednet:0000-support-trait-item-in-d…
5adeebf 
…ump, r=flip1995

Make `[clippy::dump]` support trait items

Roses are red,
violets are blue,
trait items are rare,
`[clippy::dump]` is too

---

Let's just ignore the horrible poem... anyways. While working on Marker I noticed, that `[clippy::dump]` doesn't work on trait item (See [Playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=e2d9791ffa2872e7c09a9dfbd470350c)). This simply adds support for that. `[clippy::dump]` doesn't have UI tests, to make it more resistant to changes in the AST. I tested it locally and the dump works after these changes.

---

changelog: none
# for free to join this conversation on GitHub. Already have an account? # to comment
Assignees
No one assigned
Labels
A-FFI Area: Foreign function interface (FFI) P-medium Medium priority
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@pnkfelix @emberian @arielb1 @simnalamburt @sp3d