Generate trait implementations for tuples

[jswrenn]

Emit implementations of HasField, Immutable, TryFromBytes,
FromZeros, and FromBytes for tuples of length up to 26.

Closes #274

---

• Generate trait implementations for tuples #2862

Latest Update: v6 — Compare vs v5

📚 Full Patch History

Links show the diff between the row version and the column version.

Version	Base	v1	v2	v3	v4	v5
v6	vs Base	vs v1	vs v2	vs v3	vs v4	vs v5
v5	vs Base	vs v1	vs v2	vs v3	vs v4
v4	vs Base	vs v1	vs v2	vs v3
v3	vs Base	vs v1	vs v2
v2	vs Base	vs v1
v1	vs Base

[gemini-code-assist]

Summary of Changes

Hello @jswrenn, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly extends the utility of the zerocopy library by enabling automatic trait implementations for a wide range of tuple types. By generating these implementations for tuples up to 26 elements, it simplifies working with zerocopy traits for composite data structures. Additionally, it refactors the internal logic for TryFromBytes derivation, improving code clarity and maintainability within the library itself.

Highlights

• Tuple Trait Implementations: Automatically generates implementations for HasField, Immutable, TryFromBytes, FromZeros, and FromBytes traits for Rust tuples. These implementations cover tuples with up to 26 elements.
• Refactored TryFromBytes Derivation: Introduced a new helper function, is_field_valid, in src/util/macro_util.rs to centralize the logic for checking the bit-validity of individual fields within a type. The zerocopy-derive macro for TryFromBytes now utilizes this helper, leading to more concise and maintainable generated code.
• Improved Code Generation: The changes result in cleaner and more readable generated code for TryFromBytes implementations, as demonstrated by the updated output tests.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces trait implementations for tuples up to size 26, which is a valuable addition. The implementation uses a complex but well-structured macro. The refactoring of is_bit_valid logic into a helper function is_field_valid is a good improvement for maintainability. I've found one critical issue in the derive macro that will cause compilation failures for users and needs to be addressed.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 0% with 8 lines in your changes missing coverage. Please review.
✅ Project coverage is 91.90%. Comparing base (8dfa29b) to head (42a6251).
⚠️ Report is 3 commits behind head on main.

Files with missing lines	Patch %	Lines
src/impls.rs	0.00%	8 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff            @@
##             main    #2862    +/-   ##
========================================
  Coverage   91.89%   91.90%            
========================================
  Files          20       20            
  Lines        5773     5878   +105     
========================================
+ Hits         5305     5402    +97     
- Misses        468      476     +8     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[joshlf]

It may be slightly more robust/reliable to keep the <#field_tys as ...> syntax since it makes the self type completely unambiguous. Currently not a problem, but I could theoretically see this becoming an issue if we ever change the signature of is_bit_valid to something that makes the type inference ambiguous (or worse, makes it infer as the wrong function so this silently compiles but is unsound).

[jswrenn]

I think the risk is negligible and outweighed by clarity benefits of removing a turbofish. The type of field_candidate flows directly from projection. The salient soundness condition of is_bit_valid is that every field is validated (and so we splat over #field_names); not that projection is correct. I agree that projection being incorrect would cause a soundness issue, but it'd be silly to program defensively on the assumption that project has confused the field type. And if projection is sound, there cannot be any ambiguity, since the field type is an associated type of HasField, not a parameter.

[jswrenn]

And I think we should apply this guiding principle to most other parts of our codebase. Like here, why are we programming defensively against cast returning the wrong type?

zerocopy/zerocopy-derive/src/enum.rs

Lines 343 to 350 in 4cfb5c9

	let variant = variant_md.cast::<
	#variant_struct_ident #ty_generics,
	#zerocopy_crate::pointer::cast::CastSized,
	#zerocopy_crate::pointer::BecauseInvariantsEq
	>();
	<
	#variant_struct_ident #ty_generics as #trait_path
	>::is_bit_valid(variant)