Skip to content

Cleaner macros utilizing syn::Member #18199

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

Open
wants to merge 24 commits into
base: main
Choose a base branch
from

Conversation

Bleachfuel
Copy link
Contributor

Objective

Some macros were handling Idents and indexes as seperate things, we can use syn::Member to make this more readable and nicer.

Testing

ran all revelant crate tests.

@Bleachfuel
Copy link
Contributor Author

Bleachfuel commented Mar 8, 2025

#[derive(QueryData)]
#[query_data(mutable(foo))]
//~^ ERROR: `mutable` does not take any arguments
struct MutableInvalidAttributeParameters {
    a: &'static mut Foo,
}

should we really give a error for this? seems so unnessesary and extra code. When u do this it already says "expected ,". I removed 2 of them, since the errors that syn gives are already clear. Maybe even clearer.

@alice-i-cecile alice-i-cecile added C-Code-Quality A section of code that is hard to understand or change X-Uncontroversial This work is generally agreed upon D-Straightforward Simple bug fixes and API improvements, docs, test and examples S-Needs-Review Needs reviewer attention (from anyone!) to move forward D-Macros Code that generates Rust code labels Mar 8, 2025
@alice-i-cecile alice-i-cecile requested a review from chescock April 2, 2025 19:25
@alice-i-cecile alice-i-cecile added the A-Cross-Cutting Impacts the entire engine label Apr 2, 2025
Copy link
Contributor

@chescock chescock left a comment

Choose a reason for hiding this comment

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

Yeah, this seems cleaner!

It's a little unfortunate that syn::Member doesn't have the rest of the Field value, forcing most of the uses here to do fields.iter().enumerate().filter().map() instead of just field.members(). Would it ever make sense to add our own wrapper type around a &Field and its index, along with a function to iterate them from a Fields, so that we could share a little more code here?

@Bleachfuel
Copy link
Contributor Author

Yeah we could do that, but would be better as a follow up pr

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Cross-Cutting Impacts the entire engine C-Code-Quality A section of code that is hard to understand or change D-Macros Code that generates Rust code D-Straightforward Simple bug fixes and API improvements, docs, test and examples S-Needs-Review Needs reviewer attention (from anyone!) to move forward X-Uncontroversial This work is generally agreed upon
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants