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

Fix fendermint compilation issues #499

Merged
merged 16 commits into from
Dec 22, 2023
Merged

Conversation

cryptoAtwill
Copy link
Contributor

Fix fendermint compilation issues, i.e. clippy and also format.

Currently tests are still breaking:

Caused by:
    failed to execute contract call to f410forjzm4nb2ly4r4qaqjv2xjtfc6pvhinxl5py4zi:
    code: 33
    error: <no data; potential ABI mismatch>
    info: message failed with backtrace:
    00: f065 (method 3844450837) -- contract reverted (33)
    01: f065 (method 6) -- contract reverted (33)
    02: f010 (method 2) -- send aborted with code 33 (33)
    03: f01 (method 3) -- constructor failed: send aborted with code 33 (33)
    04: f0120 (method 1) -- constructor reverted (33)
    ', fendermint/fendermint/testing/contract-test/tests/staking/machine.rs:130:14

Will fix this in follow up PR.

Comment on lines 41 to 55
checkpoint_router: ContractCaller<
DB,
CheckpointingFacet<MockProvider>,
checkpointing_facet::CheckpointingFacetErrors,
>,
topdown_router: ContractCaller<
DB,
TopDownFinalityFacet<MockProvider>,
top_down_finality_facet::TopDownFinalityFacetErrors,
>,
xnet_messaging_facet: ContractCaller<
DB,
XnetMessagingFacet<MockProvider>,
xnet_messaging_facet::XnetMessagingFacetErrors,
>,
Copy link
Contributor

@aakoshh aakoshh Dec 21, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The naming convention was WhateverFacet became whatever field, so I think these should be called checkpointing, topdown and xnet_messaging. I can't see why it's checkpoint_router and topdown_router as "router" does not appear in the type, and all of them are facets so _facet in the third is redundant.

#[derive(Clone, Debug, Serialize_tuple, Deserialize_tuple, PartialEq, Eq)]
#[derive(Clone, Debug, Serialize, Deserialize, PartialEq, Eq)]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why change these now?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we are supporting lotus related now right? Serialize_tuple produces a different result than Serialize, just be consistent with other serialization methods.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think they chose this in some cases to save on the field names. I think conceptually it's like {foo: 1, bar: "hello"} vs [1, "hello"].

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit confused because these SDK-level structs shouldn't need any kind of serialization? They are just convenience types for decoupling the contract ABIs from the application-level, right? The data from these structs is pulled into the binding-generated ABI types in create_subnet, but never serialized in this form?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bottom line: you may be able to remove the serde derive altogether here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a bit legacy code as previously it's used in lotus.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mean that these types in the past were previously serialized to feed them into legacy or Wasm actors, right? In that case, they would've been tuple-encoded. However, I suggest you simply drop the serde derivation here all together.

* CI: Build ABI for clippy

* CI: Build ABI in workflow
@@ -6,6 +6,7 @@ crytic-export/
.env
broadcast/
out/
binding/src
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aakoshh When contracts/bindings change and a dev is adjusting the SDK and other downstream components, is the expectation that they'll locally generate the bindings and adapt the dependent code, but only check in the latter and not the former? Then the CI build would generate these before trying to build and would push the updated bindings?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is up for debate, but currently I tried to follow what you said about not checking in generated code at all. So you are expected to update the SDK and Fendermint, check in those changes, but not check in the Ethers generated bindings, and CI will build it but also not push it either, it will never appear on Github.

That said, if it's useful to be able to share links to the Rust code, we can check it in. The reason I didn't do it is because people reported it changes for no reason.

However today I noticed that binding/src/lib.rs changes in a predictable way: when @cryptoAtwill pushes the modules are in alphabetical order; when I push they are in the order of appearance in build.rs. So I think there is something that formats the generated code on his end, it's not the fault of ethers being different.

permissioned: false,
permission_mode: 0, // collateral based
supply_source: ipc_actors_abis::register_subnet_facet::SupplySource {
kind: 0, // native token
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we use an enum entry here instead?

* initial investigation

* remove unused print

* remove unused print

* Update subnet activation logic (#502)

* initial attempt

* FIX: Activation

* FIX: Restrict to root

* FIX: Can checkpoint always

* FIX: Skip join if staked

* FIX: Can't checkpoint without validators

* Update machine.rs

FIX: Clippy

* Update Makefile

FIX: Docker deps

* Update lib.rs

FIX: contract path

* fix library_dependencies test.

* FIX: New ABI in test

* Non-alphabetical order

* FIX: Field names

* FIX: Fix docs after u64 became U256

---------

Co-authored-by: Akosh Farkash <aakoshh@gmail.com>
Co-authored-by: raulk <raul.kripalani@gmail.com>

---------

Co-authored-by: Akosh Farkash <aakoshh@gmail.com>
Co-authored-by: raulk <raul.kripalani@gmail.com>
@aakoshh aakoshh merged commit b569f87 into update-ipc-and-solidity Dec 22, 2023
7 checks passed
@aakoshh aakoshh deleted the fix-fendermint branch December 22, 2023 18:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants