Behavior of tests with unique feature

[silwol]

In the packaging of this crate for Debian, our autopkgtest system attempts to run the tests with different combinations of features:

• no features at all
• the default features
• one test run for every single feature enabled
• all features enabled

When running the single-feature tests, I discovered that the gte_clang_4_0 and gte_clang_6_0 fail while the other get_clang_* succeed. So first up my question, is it intended that the run gte_clang_* of tests with features individually in general should succeed, or should we just mark them as flaky?

We currently have clang-sys 0.28.1 packaged, but the behavior is the same in 0.29.3.

In case it is intended that the single feature builds succeed, below are some details:

gte_clang_4_0

Fails with multiple occurrences of the error below, reproducible by running cargo test --features="gte_clang_4_0":

error[E0412]: cannot find type `CXEvalResult` in this scope
    --> src/lib.rs:1806:51
     |
64   |         pub type $name = c_int;
     |         ----------------------- similarly named type alias `CXEvalResultKind` defined here
...
1806 |     pub fn clang_EvalResult_getAsLongLong(result: CXEvalResult) -> c_longlong;
     |                                                   ^^^^^^^^^^^^ help: a type alias with a similar name exists: `CXEvalResultKind`

caused by CXEvalResult being behind a #[cfg(feature = "gte_clang_3_9")] feature gate. Modifying this to #[cfg(any(feature = "gte_clang_3_9", feature = "gte_clang_4_0"))] makes the tests succeed.

gte_clang_6_0

Fails with multiple occurrences of the error below, reproducible by running cargo test --features="gte_clang_6_0":

error[E0412]: cannot find type `CXStringSet` in this scope
    --> src/lib.rs:1732:68
     |
1564 | / pub struct CXString {
1565 | |     pub data: *const c_void,
1566 | |     pub private_flags: c_uint,
1567 | | }
     | |_- similarly named struct `CXString` defined here
...
1732 |       pub fn clang_Cursor_getObjCManglings(cursor: CXCursor) -> *mut CXStringSet;
     |                                                                      ^^^^^^^^^^^ help: a struct with a similar name exists: `CXString`

caused by CXStringSet being behind a #[cfg(feature = "gte_clang_3_8")] feature gate. Modifying this to #[cfg(any(feature = "gte_clang_3_8", feature = "gte_clang_6_0"))] makes the tests succeed.

I don't expect my quick checks of changing the feature gates are the correct solution to the problem, just quick tests to find whether other problems occur after this one is fixed (which is not the case, the tests succeed).

[KyleMayes]

The gte_clang_* features are essentially an implementation detail, they are not intended to be enabled by users directly. Users are expected to enable one of the clang_* features instead which then enable the relevant gte_clang_* features.

These gte_clang_* features are not really necessary, they could be replaced with usage of the clang_* features but I have been too lazy to implement this change since I thought this wart only really affected the authors of this crate (i.e., me).

If I removed all of the gte_clang_* features, would it cause any problems for packaging? Or would it simplify things? I wouldn't mind removing them, wouldn't take much effort.

[silwol]

I assumed that they were more or less an implementation detail from how they are structured. This information is good enough for me to know that I can just mark them as flaky in the package. They are auto-generated by our tools, otherwise I wouldn't have taken a closer look.

If you removed these features, this would simplify the structure of the package a bit (e.g. less entries in the Provides field of the Debian package), but the gains wouldn't be massive.

I'll mark the gte_clang_* autopkgtests as flaky for now, and leave the rest up to you. Thanks for your help!

[KyleMayes]

Starting with v1.0.0 of clang-sys the gte_clang_* features have been removed.