Before this, Find() would not return a nullable Row? when Row is a value type (a struct), leading to compilation errors at best and at a struct with all fields set to 0 or null at worst.
This issue was found while updating benchmarks-cs and it's not covered by other modules/* tests, which is why I bundled it with other fixes that make benchmarks-cs compile again in the same PR. I also made a change that ensures that becnhmarks-cs actually compiles in CI (before this, it could only be executed manually).
The fix for this particular issue is in Codegen/Module.cs, while other fixes are removing IndexedAttribute (which shouldn't be exposed to the users) and adding actual indexes to the benchmarks, updating table names, using new .Find / .Filter APIs and such.
API and ABI breaking changes
If this is an API or ABI breaking change, please apply the
corresponding GitHub label.
Expected complexity level and risk
How complicated do you think these changes are? Grade on a scale from 1 to 5,
where 1 is a trivial change, and 5 is a deep-reaching and complex change.
This complexity rating applies not only to the complexity apparent in the diff,
but also to its interactions with existing and future code.
If you answered more than a 2, explain what is complex about the PR,
and what other components it interacts with in potentially concerning ways.
Testing
Describe any testing you've done, and any testing you'd like your reviewers to do,
so that you're confident that all the changes work as expected!
[x] Write a test you've completed here.
[ ] Write a test you want a reviewer to do here, so they can check it off when they're satisfied.
Description of Changes
Before this,
Find()would not return a nullableRow?whenRowis a value type (astruct), leading to compilation errors at best and at a struct with all fields set to0ornullat worst.This issue was found while updating benchmarks-cs and it's not covered by other
modules/*tests, which is why I bundled it with other fixes that make benchmarks-cs compile again in the same PR. I also made a change that ensures thatbecnhmarks-csactually compiles in CI (before this, it could only be executed manually).The fix for this particular issue is in
Codegen/Module.cs, while other fixes are removingIndexedAttribute(which shouldn't be exposed to the users) and adding actual indexes to the benchmarks, updating table names, using new.Find/.FilterAPIs and such.API and ABI breaking changes
If this is an API or ABI breaking change, please apply the corresponding GitHub label.
Expected complexity level and risk
How complicated do you think these changes are? Grade on a scale from 1 to 5, where 1 is a trivial change, and 5 is a deep-reaching and complex change.
This complexity rating applies not only to the complexity apparent in the diff, but also to its interactions with existing and future code.
If you answered more than a 2, explain what is complex about the PR, and what other components it interacts with in potentially concerning ways.
Testing
Describe any testing you've done, and any testing you'd like your reviewers to do, so that you're confident that all the changes work as expected!