Move the Jet codec and parser towards the object-safaty

[ivanlele]

This PR moves the Jet::decode method to JetEnvironment::decode_jet, introduces a parse method for jets within that environment, and updates Jet::encode to comply with object safety. See #349 for details.

[ivanlele]

@apoelstra. Looks big at first glance, but it's mostly from moving the decoding tree into autogenerated files, once I revert those, it'll be tiny. Also the updated generation: BlockstreamResearch/simplicity#335

[apoelstra]

utACK 4d89a8f -- looking forward to getting the Simplicity PR in (I fixed my pinning so hopefully I can merge it today)

[ivanlele]

@apoelstra with your ACK in BlockstreamResearch/simplicity/335, should I go ahead and revert the autogenerated files here?

[apoelstra]

@ivanlele yes -- sorry, the only reason I haven't merged it is because my local tests have been delayed.

[ivanlele]

@ivanlele yes -- sorry, the only reason I haven't merged it is because my local tests have been delayed.

Np! I reverted 4bef6bb, rolled back the autogenerated files, and temporarily reverted some logic to match the previous interfaces. The diff looks a bit funny:
https://github.com/ivanlele/rust-simplicity/pull/9/changes

I’m not sure it's worth merging this right now. Maybe we should keep it as a draft until the new version is ready? I can open a follow-up PR to remove the remaining not object safe supertraits, and then we can merge both PRs together after the new version comes. After these 2, Jet should be fully object safe

[apoelstra]

I’m not sure it's worth merging this right now. Maybe we should keep it as a draft until the new version is ready?

What do you mean by this. Other than merging 335 (which I did) what needs to be done?

[ivanlele]

I’m not sure it's worth merging this right now. Maybe we should keep it as a draft until the new version is ready?

What do you mean by this. Other than merging 335 (which I did) what needs to be done?

After reverting autogen, the only changes in the diff are small updates to the encode functions to support dynamic dispatch (around 20 lines). I was thinking that this might be too little to justify a PR, but I may be overthinking it.

If this looks fine to you, I can squash the revert and these changes into a single commit, push it, and you can review and then merge

[apoelstra]

If this looks fine to you, I can squash the revert and these changes into a single commit, push it, and you can review and then merge

TBH I'm not sure what you're doing with the revert -- now that 335 is merged, you should update the vendored version of libsimplicity, which will pull in all the changes from there. This is the only allowed way to update the autogenerated files.

It's okay to squash any additional changes; I can just redo the revendoring on my end and then diff to see what you did.

[ivanlele]

you should update the vendored version of libsimplicity

Can I just do that? I thought, we could only revendor and regenerate after a new version of rust-simplicity is released (maybe I'm was confused). If that's not the case, it simplifies things a lot.

Should I go ahead and include the revendoring and regeneration in this PR?

[apoelstra]

Can I just do that?

Yes :).

I thought, we could only revendor and regenerate after a new version of rust-simplicity is released

Nope. If we revendor/regenerate then we've committed to a major release (rather than a minor one) but we're not obligated to, and we don't need to do a release beforehand.

I think, last time we revendored we had some other changes that we really wanted to get into a minor release, so we did that minor release before revendoring. But that's not the case now.

Should I go ahead and include the revendoring and regeneration in this PR?

Yes please.

[ivanlele]

@apoelstra lmk if the commit order looks good for you

[apoelstra]

@ivanlele I'm not sure what I'm looking at with 4bef6bb (the first "revert env removal" commit). Is this what happens when you update the upstream lib and revendor?

I would suggest squashing all three commits rather than worrying about their order. I will do the revendoring on my end and then run git diff against your commit to see what non-mechanical changes you made.

[ivanlele]

I would suggest squashing all three commits rather than worrying about their order. I will do the revendoring on my end and then run git diff against your commit to see what non-mechanical changes you made.

done

[apoelstra]

ACK bb63bff; successfully ran local tests