Fuel merge part 3 - Start working on EventMod codegen - #150

DZakh · 2024-08-27T12:09:21Z

LogId is correctly generated in the topic0 var
Started generating all EventMod variables on the Rust side, to be able to pass the Fuel implementation
Improved rescript_types module. I don't know whether it's possible in Evm, but now we also support args starting with numbers and uppercase letters

DZakh · 2024-08-27T15:51:38Z

-
-    let eventArgsSchema = S.literal(%raw(`null`))->S.variant((. _) => ())
-
-    external convertHyperSyncEventArgs: HyperSyncClient.Decoder.decodedEvent => eventArgs = "%identity"


The only regression is that it's not runtime-free anymore, but everything else should work the same as before.

Doesn't the Utils.magic function become zero cost during optimization steps?

Only when the function is called from the same file

JonoPrest · 2024-08-28T09:01:57Z

+    Params(Vec<EventParam>),
+    Data(RescriptTypeIdent),


I'm pretty keen to use the same way of generating types for EVM in future. It's nice because it easily supports nested record types which we currently just inline as tuples.

Sounds good, the only problem I see is building a hyperSyncConverter function

Hmmm, yeah, but we should be able to lookup nested types and codegen a converter without too much trouble.

Should work, but what about the is_indexed?

Should work, but what about the is_indexed?

Well, we should generate the converter from the EVM event, not the rescript type. If you add an index to a nested struct/tuple/array, the actual data doesn't get stored on chain. Just a keccak hash so we don't really have to handle params that are a nested index structure.

JonoPrest · 2024-08-28T09:15:17Z

+            name: event_config.name,
+            event,
+            payload: EventPayload::Data(log.data_type),
+            topic0: log.id,


Is it appropriate to call fuel's log.id a sighash?

If so maybe we rename topic0 to sighash as a convention. Since topic0 is the sighash of an evm event.

Yes, I think it's something like this. I'll change this in the next PR.

Done in the PR

JonoPrest · 2024-08-28T09:17:01Z

+        let event: NormalizedEthAbiEvent =
+            Event::get_abi_event(&format!("{}()", event_config.name), &None)?.into();


Cool so this is just a stub with an empty event for now? Need to relook at the data structure.

Unfortunately it's still used in some places, so I couldn't get rid of it yet.

JonoPrest · 2024-08-28T09:44:05Z

+    const DECODE_HYPER_FUEL_DATA_CODE: &'static str =
+        "(_) => Js.Exn.raiseError(\"HyperFuel decoder not implemented\")";

+    pub fn generate_convert_hyper_sync_event_args_code(params: &Vec<EventParam>) -> String {


Can we handle the empty vec in this function so the context makes a bit more sense?

So check if it's empty and return the (Utils.magic: HyperSyncClient.Decoder.decodedEvent => eventArgs) here if so.

JonoPrest · 2024-08-28T09:46:56Z

+                    let template_params = params
+                        .iter()
+                        .map(|input| {
+                            let res_type = abi_to_rescript_type(&input.into());
+                            let js_name = input.name.to_string();
+                            EventParamTypeTemplate {
+                                res_name: RescriptRecordField::to_valid_res_name(&js_name),
+                                js_name,
+                                default_value_rescript: res_type.get_default_value_rescript(),
+                                default_value_non_rescript: res_type
+                                    .get_default_value_non_rescript(),
+                                res_type: res_type.to_string(),
+                                is_eth_address: res_type == RescriptTypeIdent::Address,
+                            }
+                        })
+                        .collect::<Vec<_>>();
+
+                    let data_type_expr = RescriptTypeExpr::Record(
+                        params
+                            .iter()
+                            .map(|p| {
+                                RescriptRecordField::new(
+                                    p.name.to_string(),
+                                    abi_to_rescript_type(&p.into()),
+                                )
+                            })
+                            .collect(),
+                    );


Lets remove the above if else check and then if params are empty just make unit type expression and the rest of the logic can remain the same.

JonoPrest · 2024-08-28T09:48:39Z

+                name,
+                params: vec![],
+                data_type: type_indent.to_string(),
+                data_schema_code: type_indent.to_rescript_schema(),
+                topic0: config_event.topic0.to_string(),
+                convert_hyper_sync_event_args_code:
+                    "(Utils.magic: HyperSyncClient.Decoder.decodedEvent => eventArgs)".to_string(),
+                decode_hyper_fuel_data_code: Self::DECODE_HYPER_FUEL_DATA_CODE.to_string(),
+            }),


Actually this case can be covered as well. All we want to do on the match of these types is return a rescript type expression.

It'll change in the future with the decode_hyper_fuel_data_code implementation.

JonoPrest · 2024-08-28T09:56:45Z

+            vec![],
+        );
+
+        let expected = r#"type myRecord = {@as("module") module_: bool, @as("") _: bool, @as("1") _1: bool, @as("Capitalized") capitalized: bool, dashed-field: bool}"#.to_string();


What's happening with dash-field? If you want, there's a lib I installed called convert_case which you could transform kebab to camel or snake case for eg.

It'll codegen like this dashed-field: bool and break during compilation. I think we don't have a case for this yet, so I just ignored it.

JonoPrest

Looks great Dmitry. I see a lot of conflicts about to happen with my current PR 😅

DZakh added 10 commits August 27, 2024 16:07

Uncomment fuel codegen

a906280

Update fuel greeter test handler

97050f5

Codegen rb as topic0 field for Fuel events

9e5cb7b

Prepare Event for Fuel data codegen

4b94944

Generate decoders on the Rust side

0978ec7

Generate event data type on Rust side

1d7591f

Use rust to generate event args rescript schema

3c4b1be

Wip Fuel event types implementation

a1a05c2

Block fuel codegen

08bcf8a

Fix contract import for fuel

8806aec

DZakh changed the title ~~Fuel merge part 3 - wip~~ Fuel merge part 3 - Start working on EventMod codegen Aug 27, 2024

DZakh requested a review from JonoPrest August 27, 2024 15:50

DZakh commented Aug 27, 2024

View reviewed changes

JonoPrest reviewed Aug 28, 2024

View reviewed changes

DZakh added 2 commits August 28, 2024 13:58

Simplify event template for empty params

ab0d6d4

Rename topic0 to sighash

efacf82

JonoPrest approved these changes Aug 28, 2024

View reviewed changes

DZakh merged commit 253ce2f into main Aug 28, 2024

DZakh deleted the dz/fuel-merge-4 branch August 28, 2024 10:09


		let eventArgsSchema = S.literal(%raw(`null`))->S.variant((. _) => ())

		external convertHyperSyncEventArgs: HyperSyncClient.Decoder.decodedEvent => eventArgs = "%identity"

		let event: NormalizedEthAbiEvent =
		Event::get_abi_event(&format!("{}()", event_config.name), &None)?.into();

Uh oh!

Conversation

DZakh commented Aug 27, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DZakh Aug 28, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JonoPrest left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

DZakh commented Aug 27, 2024 •

edited

Loading

DZakh Aug 28, 2024 •

edited

Loading