feat(derive) fields derive visibility from original struct

[Reinsdyret]

Fields now derive the visibility from original structs, instead of just pub.

[Reinsdyret]

@aapoalas @omfj I'm unsure about the linting errors here, why didnt these trigger before?
Should I add ignores for all the errors?

[aapoalas]

@aapoalas @omfj I'm unsure about the linting errors here, why didnt these trigger before? Should I add ignores for all the errors?

They weren't triggering because the fields were all public and the type was public, so in a library it meant that they could be used by users of the library. Now that we've made them private (inaccessible to users of the library), the linter can see that the fields are never accessed here in the library and they cannot be accessed from the outside. Hence, they are not unused and could be removed.

We should add #[expect(dead_code)] I think (or #[allow(...)] but expect is stronger and thus generally better).

[Reinsdyret]

We should add #[expect(dead_code)] I think (or #[allow(...)] but expect is stronger and thus generally better).

I've tried adding expect or allow on the structs and on all fields and errors persist. I think its from the -D warnings in clippy, we can add -A dead_code to allow dead code warnings but i dont know any other solution

[aapoalas]

We should add #[expect(dead_code)] I think (or #[allow(...)] but expect is stronger and thus generally better).

I've tried adding expect or allow on the structs and on all fields and errors persist. I think its from the -D warnings in clippy, we can add -A dead_code to allow dead code warnings but i dont know any other solution

Try adding the #[allow(dead_code)] at the top level of the integration.rs and then in the other "scopes" where the linter is complaining.

EDIT: Actually no wait: it's best if we just add #[allow(dead_code)] in the output of the SoAble derive. Each of the generated Ref/Mut/Slice/SliceMut types should be marked with #[allow(dead_code)], as we generate them regardless of if they're used.