Skip to content

Conversation

@parched
Copy link

@parched parched commented Sep 3, 2025

This matches the behavior of flatc.

This feels a little hacky but this is my first time seeing larlpop so I'm unsure if there's a better way.
Guidance on suitable tests would be appreciated too.

The specific use case I have is fields called attribute.

Checklist

  • Updated CHANGELOG.md with relevant changes
  • Added tests for any new/fixed functionality
  • Added/updated documentation for new/changed code
  • Checked that README.md still makes sense (and updated it if necessary)

This matches the behavior of flatc
@TethysSvensson
Copy link
Collaborator

I don't know if there is a better way either but I think this approach is probably good enough.

You can add tests in the test/files/invalid and test/files/valid directories to test the core parsing.

However I think it also makes sense to test the code generation in this case. That would be in test/rust-test-2021/api_files.

I think using keywords as identifiers is a bit cursed, but I'm not inherently against it. I'll take a better look later.

@TethysSvensson
Copy link
Collaborator

By the way, is there anything preventing you from simply renaming the field to something that isn't a reserved keyword?

@parched
Copy link
Author

parched commented Sep 7, 2025

By the way, is there anything preventing you from simply renaming the field to something that isn't a reserved keyword?

I would have to update the thousand-odd places we currently use it in our codebase -- it isn't a simple find-and-replace because the word is used in other contexts too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants