-
Notifications
You must be signed in to change notification settings - Fork 1.1k
ctest-next: miscellaneous filtering bug fixes #4613
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.
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
base: main
Are you sure you want to change the base?
Conversation
51cf365
to
d1382d3
Compare
9d9d43f
to
e96f64c
Compare
filtered_ffi_items: FfiItems, | ||
ffi_items: &'a FfiItems, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this need to keep the unfiltered ffi_items
at all anymore? It seems cleaner to only keep the filtered items here, if possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's to fix one of the bugs, if say a struct T1Bar
is skipped for testing it won't be in filtered_ffi_items
, but if some other test for a different struct returns a *const T1Bar
, then it would fail to realize that T1Bar
is a struct, since originally we were using the filtered_ffi_items
in c_type
.
libc-test/test/main_next.rs
Outdated
#![allow(unused_imports, deprecated)] | ||
|
||
use libc::*; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can unused_imports
apply only to this libc::*
import? So we don't apply it to the contents of main_next.rs
.
e96f64c
to
38c56f1
Compare
38c56f1
to
a0c27ab
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the tests I left a few comments at #4600 (comment) before realizing they were part of this PR, could you apply them here?
let skipped: Vec<_> = self | ||
.filtered_ffi_items | ||
.$field | ||
.extract_if(.., |item| { | ||
self.generator | ||
.skips | ||
.iter() | ||
.any(|f| f(&MapInput::$variant(item))) | ||
|| (self.generator.skip_private && !item.public) | ||
}) | ||
.collect(); | ||
if verbose { | ||
skipped | ||
.iter() | ||
.for_each(|item| eprintln!("Skipping {} \"{}\"", $label, item.ident())); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No need to collect to an intermediate Vec
:
let skipped = self
.filtered_ffi_items
// ...
.extract_if(/* ... */);
for item in skipped {
if verbose {
eprintln!("...");
}
}
Also, put the self.generator.skip_private && !item.public
check before checking self.generator.skips
, so it doesn't need to test all the skips if there is an easy return.
// For structs/unions/aliases, their type is the same as their identifier. | ||
MapInput::Alias(a) => (a.ident(), cdecl::named(a.ident(), cdecl::Constness::Mut)), | ||
MapInput::Struct(s) => (s.ident(), cdecl::named(s.ident(), cdecl::Constness::Mut)), | ||
MapInput::Union(u) => (u.ident(), cdecl::named(u.ident(), cdecl::Constness::Mut)), | ||
// FIXME(ctest): For some specific primitives such as c_uint, they don't exist on the | ||
// C side and have to be manually translated. If they are removed to use `std::ffi`, | ||
// then this becomes unneeded (although it won't break). | ||
MapInput::Alias(a) => (a.ident(), cdecl::named(a.ident(), Constness::Mut)), | ||
MapInput::Struct(s) => (s.ident(), cdecl::named(s.ident(), Constness::Mut)), | ||
MapInput::Union(u) => (u.ident(), cdecl::named(u.ident(), Constness::Mut)), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the FIXME here? This part doesn't have to do with primitives.
// This is done to deal with things like 3usize. | ||
syn::Expr::Index(i) => { | ||
let base = translate_expr(&i.expr); | ||
let index = translate_expr(&i.index); | ||
format!("{base}[{index}]") | ||
} | ||
syn::Expr::Lit(l) => match &l.lit { | ||
syn::Lit::Int(i) => i.base10_digits().to_string(), | ||
_ => l.to_token_stream().to_string(), | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is that comment above the right block? For the integer parts, you can turn e.g. 3usize
into ((size_t)(3))
to keep the type around.
Could you make sure this is tested in ctest-next/src/tests.rs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(updating the status)
Description
Prepares for porting
libc-test
platforms to usectest-next
by fixing numerous bugs. #4600 and #4610 both depend on this PR, so this should be merged first.Fixes:
ctest-next
in the future, which is a edition 2024 crate.translate_expr
to support translating[ty; 3usize]
properly.ctest-next
backed platforms.ffi_items
to theTranslateHelper
sincetemplate.rs
does the test filtering for consistency.struct const StructName*
, and sometimes the struct label would not be applied at all.Sources
Checklist
libc-test/semver
have been updated*LAST
or*MAX
areincluded (see #3131)
cd libc-test && cargo test --target mytarget
);especially relevant for platforms that may not be checked in CI