Skip to content
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

tbv2: delegate is required for complex processors when write should work #466

Open
JakeHillion opened this issue Jan 23, 2024 · 0 comments
Labels
codegen Code Generation Framework

Comments

@JakeHillion
Copy link
Contributor

When writing container implementations for some complex types it makes sense to extract multiple component numbers from the data buffer in one go. For example it would be natural to write processors like this:

[codegen.processor]
type = "types::st::Pair<DB, types::st::VarInt<DB>, types::st::Pair<DB, types::st::VarInt<DB>, types::st::VarInt<DB>>>"
func = "..."
[codegen.processor]
type = "types::st::List<DB, types::st::VarInt<DB>>"
func = "..."

This generally works and should be a supported pattern.

traversal_func = '''
auto tail = returnArg.write(a)
    .write(b)
    .write(c)
    .write(listLength);
for (auto&& it : container) {
  tail = tail.delegate([&ctx, &it](auto ret) {
    return OIInternal::getSizeType<Ctx>(ctx, it, ret);
  });
}
return tail.finish();
'''

However, this doesn't work. The chained writes are invalid because it's attempting to write to a Pair<Pair<VarInt, ...>, ...>.

The generated type is (DB omitted for clarity):
using type = Pair<Pair<VarInt, Pair<VarInt, VarInt>>, List<VarInt>>

At least for this layer this is really easy to fix. Instead of guaranteeing the first pair returns a Unit from the write, see what it returns and instead return a Pair<decltype(first.write(X)), second>. I think this scales too.

@JakeHillion JakeHillion added the codegen Code Generation Framework label Jan 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
codegen Code Generation Framework
Projects
None yet
Development

No branches or pull requests

1 participant