Skip to content

Conversation

@mbyx
Copy link
Contributor

@mbyx mbyx commented Aug 15, 2025

Description

Adds the ability to specify whether a type alias and a set of constants that use that type alias maps to a C enum, as well as the ability to skip them.

Sources

Checklist

  • Relevant tests in libc-test/semver have been updated
  • No placeholder or unstable values like *LAST or *MAX are
    included (see #3131)
  • Tested locally (cd libc-test && cargo test --target mytarget);
    especially relevant for platforms that may not be checked in CI

@rustbot rustbot added ctest Issues relating to the ctest crate S-waiting-on-review labels Aug 15, 2025
@mbyx
Copy link
Contributor Author

mbyx commented Aug 15, 2025

The signededness of a C enum is implementation defined, so should that test be skipped for all C enums?

/// let mut cfg = TestGenerator::new();
/// cfg.c_enum(|e| e == "pid_type");
/// ```
pub fn c_enum(&mut self, f: impl Fn(&str) -> bool + 'static) -> &mut Self {
Copy link
Contributor

@tgross35 tgross35 Aug 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this take &Type rather than &str? To match rename_alias.

Maybe the name alias_is_c_enum would be a bit more descriptive, there are a handful of ways to represent C enums https://mdaverde.com/posts/rust-bindgen-enum/

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It can't, because it's also used to filter out constants with the same type. The only way to do it would be to create a Type struct in that method, but then the public and ty fields would be incorrect.

@tgross35
Copy link
Contributor

The signededness of a C enum is implementation defined, so should that test be skipped for all C enums?

repr(C) should generally match. I know there might be some problems with that, but have you run into any here?

Could you add a test in ctest-test to ensure this catches incorrect item values and things like the wrong repr type?

@mbyx
Copy link
Contributor Author

mbyx commented Aug 15, 2025

If I use an unsigned type in simple.h for the enum, it fails on the signededness test on windows. If I use a signed type it fails on linux. This isn't really a problem in the actual ports because the windows port doesn't use enums, but these integration tests are run on all platforms.

@tgross35
Copy link
Contributor

I think that's actually an important catch; the fallback here

(@ty) => { $crate::c_uint };
should probably be updated so the type is signed on Windows.

@mbyx
Copy link
Contributor Author

mbyx commented Aug 18, 2025

The signededness of a C enum is implementation defined, so should that test be skipped for all C enums?

repr(C) should generally match. I know there might be some problems with that, but have you run into any here?

Could you add a test in ctest-test to ensure this catches incorrect item values and things like the wrong repr type?

Since it piggybacks on tests for constants, incorrect item values would be caught with that. As for the repr type I'm not sure how to catch that. If it uses too small a repr size the constant test would overflow and catch it. For now ctest-test is only run on one platform, but on others a different type would have to be used.

@mbyx mbyx force-pushed the ctest-c-enum branch 4 times, most recently from 8a40344 to 910290e Compare August 18, 2025 16:10
@mbyx
Copy link
Contributor Author

mbyx commented Aug 18, 2025

FreeBSD is strange. A lot of the times it segfaults on macros.rs, but it only seems to segfault when rustc is called.

Copy link
Contributor

@tgross35 tgross35 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The signededness of a C enum is implementation defined, so should that test be skipped for all C enums?

repr(C) should generally match. I know there might be some problems with that, but have you run into any here?
Could you add a test in ctest-test to ensure this catches incorrect item values and things like the wrong repr type?

Since it piggybacks on tests for constants, incorrect item values would be caught with that. As for the repr type I'm not sure how to catch that. If it uses too small a repr size the constant test would overflow and catch it. For now ctest-test is only run on one platform, but on others a different type would have to be used.

I think this could look something like this:

pub type enum_repr_too_small = u16;
pub const ENUM_REPR_TOO_SMALL_A: enum_repr_too_small = 0;

#[cfg(windows)]
pub type enum_wrong_signedness = i32;
#[cfg(not(windows))]
pub const ENUM_WRONG_SIGNEDNESS_A: enum_wrong_signedness = 0;

mapping to C:

enum enum_repr_too_small {
    ENUM_REPR_TOO_SMALL_A;
}

enum enum_wrong_signedness {
    ENUM_WRONG_SIGNEDNESS_A;
}

And then set these as alias_is_c_enum. Then the test at

fn t2() {
should see the right outputs

src/macros.rs Outdated
Comment on lines 282 to 284
(@ty_win $repr:ty) => { $repr };
(@ty) => { $crate::c_uint };
(@ty_win) => { $crate::c_int };
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of using different macro arms, add a pub(crate) type CEnumRepr to src/types.rs and use it here.

This will also simplify the tests, you can do e.g. 0 as CEnumRepr rather than splitting on Windows

@mbyx mbyx force-pushed the ctest-c-enum branch 3 times, most recently from 4bc09f1 to d212197 Compare August 19, 2025 05:57
@mbyx mbyx requested a review from tgross35 August 19, 2025 06:14
@tgross35 tgross35 added this pull request to the merge queue Aug 19, 2025
Merged via the queue into rust-lang:main with commit 192bccb Aug 19, 2025
50 of 52 checks passed
@tgross35 tgross35 added the stable-unneeded This PR is applied to main but already exists on libc-0.2 label Sep 19, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ctest Issues relating to the ctest crate stable-unneeded This PR is applied to main but already exists on libc-0.2

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants