Skip to content

ctest: add tests for field size, offset, and field ptr #4561

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

Merged
merged 1 commit into from
Jul 28, 2025

Conversation

mbyx
Copy link
Contributor

@mbyx mbyx commented Jul 23, 2025

Description

Adds tests for checking if the size and offset of a field is the same in Rust and C, as well as the pointer to that field.

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 Jul 23, 2025
@mbyx mbyx force-pushed the ctest-field-test branch from ce1a907 to 9848a68 Compare July 23, 2025 13:34
@mbyx mbyx force-pushed the ctest-field-test branch from 9848a68 to 46f0c4e Compare July 24, 2025 05:39
@mbyx mbyx requested a review from tgross35 July 24, 2025 05:43
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.

With these two small changes, the size+offset changes look good to me. I do have some more feedback for the field pointer tests though; maybe want to split that off to another PR so the rest of this can merge now?

@mbyx mbyx force-pushed the ctest-field-test branch 2 times, most recently from b3008cb to 8996f9b Compare July 24, 2025 07:12
@mbyx
Copy link
Contributor Author

mbyx commented Jul 24, 2025

It's fine to review the field ptr checks now, splitting it would be harder.

@mbyx mbyx requested a review from tgross35 July 24, 2025 07:14
Comment on lines 514 to 534
pub(crate) fn translate_signature_returning_ptr(
&self,
signature: &str,
return_type: &syn::Type,
) -> Result<String, TranslationError> {
Copy link
Contributor

Choose a reason for hiding this comment

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

This can be a general cdecl generator right, not specific to signatures anymore right? Maybe translate_signature_returning_ptr -> make_cdecl, signature -> name, and return_type -> ty.

Comment on lines 527 to 559
if let syn::PathArguments::AngleBracketed(args) = &last.arguments {
if let syn::GenericArgument::Type(inner_ty) = args.args.first().unwrap() {
// Option<T> is ONLY ffi-safe if it contains a function pointer, or a reference.
match inner_ty {
syn::Type::Reference(_) | syn::Type::BareFn(_) => {
return self.translate_signature_returning_ptr(signature, inner_ty);
}
_ => {
return Err(TranslationError::new(
TranslationErrorKind::NotFfiCompatible,
&p.to_token_stream().to_string(),
inner_ty.span(),
));
}
}
}
}
Copy link
Contributor

Choose a reason for hiding this comment

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

There is some similar logic for handling Option elsewhere isn't there? Could this reuse the valid type checks?

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 was duplicated in the previous PR, but not anymore.

return Ok(format!("{elem_type} (*{signature})[{len_outer}]"));
}
}
_ => (),
Copy link
Contributor

Choose a reason for hiding this comment

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

Should unknown types return an error?

@@ -291,4 +458,139 @@ impl<'a> TranslateHelper<'a> {

Ok(self.generator.map(item))
}

Copy link
Contributor

Choose a reason for hiding this comment

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

All of the below functions are related to translating more complex Rust types to C types, not directly related to filling out the template. Could they be in the translator module, possibly as methods on Translator?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

basic_c_type and make_cdecl require ffi_items and generator, so I think it would be better to keep them here. translate_signature_partial depends on basic_c_type as well.


let uninit_ty = MaybeUninit::<{{ item.id }}>::zeroed();
let ty_ptr = uninit_ty.as_ptr();
// SAFETY: We don't read `field_ptr`, only compare the pointer itself.
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
// SAFETY: We don't read `field_ptr`, only compare the pointer itself.
// SAFETY: We don't read `field_ptr`, only compare the pointer itself. The assumption is made that
// this does not wrap the address space.

Learned there is another precondition here

@mbyx mbyx force-pushed the ctest-field-test branch 4 times, most recently from 9b70c53 to 10163a4 Compare July 26, 2025 15:09
@mbyx mbyx force-pushed the ctest-field-test branch from 10163a4 to c0f059c Compare July 26, 2025 15:12
@mbyx mbyx requested a review from tgross35 July 26, 2025 15:17
@tgross35 tgross35 added this pull request to the merge queue Jul 28, 2025
Merged via the queue into rust-lang:main with commit c9bbba5 Jul 28, 2025
48 of 52 checks passed
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
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants