libc-test: Switch Linux to ctest-next

[mbyx]

Description

Ports the linux platform to also be tested using ctest-next.

Blocked on #4674.

For now it skips tests for pid_type and proc_cm_event C enums (technically they weren't tested before either) because C seems to hide them in userspace.

Sources

Checklist

• Tested locally (cd libc-test && cargo test --target mytarget);
  especially relevant for platforms that may not be checked in CI

[mbyx]

Uh oh, I forgot that the enum problem still existed. The other error seems to be a missing cfg probably. This will probably be blocked for a bit longer then.

[mbyx]

So the temporary fix to the enum problem mostly works, but it does still seem like pid_type and its constants are not being found. I'd like to wait a bit longer on this port, and actually figure out why the original ctest does not have to deal with these enums.

[mbyx]

I tested in a completely new crate with the old ctest cloned beside it, it seems that it can't detect an item wrapped inside of the c_enum macro, effectively hiding it from ctest.

Then I started doing some print debugging in the old ctest, and from what I can understand, given a crate that only has the c_enum macro and an invocation of that macro, after expanding the crate with

let krate = ecx.monotonic_expander().expand_crate(krate);

it seems to just leave the macro definition behind, deleting the invocation in its internal representation.

Then I switched to a crate with only the s and __item macros and an invocation of s, but mysteriously that worked without issue. Same with the e and __item macros.

At first I thought it was because of a lack of using __item in c_enum, so I modified c_enum to use it, but even that didn't work.

So I think that all this time ctest has just quietly been ignoring c_enum invocations. (Which would be easy to check, just run libc-test on linux and look at the generated files, (I can't because the original ctest fails on WSL for me it does actually generate the files at least, and they don't have any item that was inside of a c_enum invocation).

[mbyx]

Assuming that in fact c_enum hasn't been checked at all, then for most cases, just adding the enum keyword for known c_enums should work. This is also what worked for freebsd.

Here however, exactly one enum pid_type, seems to be missing, despite being included from sched.h. Is pid_type somehow made private on the C side?

[tgross35]

This is done in the global config now, right?

[mbyx]

If pid_type can't be tested, then its best to block this on #4658, so that skipping pid_type is just a one liner.

[mbyx]

Just one error left. It seems to be related to 64 and 32 bit time. The test fails on a 32 bit platform with 64 bit time, so it wants to use __suseconds_t but can't find it. @tgross35, would this be related to the multiple time related PRs or is it just a cfg issue?

EDIT: It was the same issue as everything else has been so far, the target wasn't specified for expansion correctly.