Skip to content
New issue

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

Sign up for GitHub

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

Already on GitHub? Sign in 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in 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