need to deprecate binary_codec_sv2 and restructure binary_sv2 + derive_codec_sv2

[Shourya742]

The current structure of binary_sv2 does not follow best practices. Typically, a crate defining a proc_macro only includes an additional crate for the macro’s implementation. However, in binary_sv2, we have two separate crates—one for the proc_macro implementation and another for the primitives required for macro scaffolding. Due to the tightly coupled nature of the proc_macro implementation with the module structure, restructuring it requires rewriting some parts of the macro to align with the proposed design.

Kudos to @plebhash for pointing this out and suggesting a better structure: #1459 (comment)

[plebhash]

one detail coming from #1459 that we should clean up here is some leftover lifetime parameters that were originally motivated by serde support:

reference: 3f80718#r1947844273

[Shourya742]

Reimplement or redesign parts of proc_macro in derive_codec to work around bugs like this: #1468 (comment).

[plebhash]

this will introduce breaking changes to binary_sv2 APIs

[plebhash]

this will introduce breaking changes to binary_sv2 APIs

as a consequence, we will have to refactor framing_sv2, which could also be a good opportunity to improve APIs there

[Levi0804]

Reimplement or redesign parts of proc_macro in derive_codec to work around bugs like this: #1468 (comment).

Hey, Would it be a good idea to start with introducing quote and syn in code? Also, regarding #1468 (comment) I think we can return a more appropriate error message, something like 'the name of the field cannot be data.' or we could prefix data with an _ or rename it appropriately. What are your thoughts on this?

[plebhash]

Reimplement or redesign parts of proc_macro in derive_codec to work around bugs like this: #1468 (comment).

Hey, Would it be a good idea to start with introducing quote and syn in code? Also, regarding #1468 (comment) I think we can return a more appropriate error message, something like 'the name of the field cannot be data.' or we could prefix data with an _ or rename it appropriately. What are your thoughts on this?

SRI leans towards a conservative policy on dependencies for low-level crates

as much as quote and syn could allow for elegant solutions, my stance here is that we should stick with the current strategy of no external dependencies, and only refactor the parts of the code that would allow for the task described on this issue

[Levi0804]

Reimplement or redesign parts of proc_macro in derive_codec to work around bugs like this: #1468 (comment).

@plebhash I understand. Would it be alright if I work on this? I'll look into this and any similar bugs that might arise.

[Shourya742]

Reimplement or redesign parts of proc_macro in derive_codec to work around bugs like this: #1468 (comment).

Hey, Would it be a good idea to start with introducing quote and syn in code? Also, regarding #1468 (comment) I think we can return a more appropriate error message, something like 'the name of the field cannot be data.' or we could prefix data with an _ or rename it appropriately. What are your thoughts on this?

We can refine this approach. If you are familiar with MIR, you can leverage constructs that are valid in MIR but not in Rust source code. This can help in solving the problem. I recommend starting with some good first issues to better understand the codebase first.

[Levi0804]

Reimplement or redesign parts of proc_macro in derive_codec to work around bugs like this: #1468 (comment).

Hey, Would it be a good idea to start with introducing quote and syn in code? Also, regarding #1468 (comment) I think we can return a more appropriate error message, something like 'the name of the field cannot be data.' or we could prefix data with an _ or rename it appropriately. What are your thoughts on this?

We can refine this approach. If you are familiar with MIR, you can leverage constructs that are valid in MIR but not in Rust source code. This can help in solving the problem. I recommend starting with some good first issues to better understand the codebase first.

Understood, I'll look into some good first issues. I am not very familiar with MIR, I’ll start exploring it.

[plebhash]

as discussed in the dev call, we're going to leave this refactoring for some time in the future

for now, it will be sufficient to fix #1473