[fastx distsys] Adapt fastpay client into fastnft client handling objects #7
Assignees
Comments
gdanezis
changed the title
|
PR #29 added Vec<ObjectID> to ClientState, which resolves part of this issue, there are a few task outstanding to fully adapt fast pay client into fastnft client, I will create a few more issues to address them. |
awelc
added a commit
that referenced
this issue
Jan 6, 2025
## Description
It looks like locals are currently not disassembled correctly when
running Move disassembler and this PR contains a fix. In particular,
consider the following Move code:
```move
module test::M1;
public enum SomeEnum has drop, copy {
NamedVariant { field: u64 },
PositionalVariant(u64),
}
public fun foo(e: SomeEnum, p1: u64, p2: u64): (u64, u64) {
match (e) {
SomeEnum::NamedVariant { field } => {
let mut res = field + p1;
res = res + p2;
(res, res)
},
SomeEnum::PositionalVariant(field) => (field, field)
}
}
#[test]
public fun test() {
let e = SomeEnum::NamedVariant { field: 42 };
foo(e, 42, 7);
}
```
When running disassembler on the `M1` module, the following 3 locals are
reported in the disassembly:
```
L0: __match_tmp%#unpack_subject#1#1#0: SomeEnum
L1: field#3#0: u64
L2: res#1#0: u64
```
However, 6 locals are reported in the source map:
```
%#7
%#8
__match_tmp%#match_subject#2#2#0
__match_tmp%#unpack_subject#1#1#0
field#3#0
res#1#0
```
The same number of locals is also reported in the trace generated out of
the test function in `M1`.
It looks like the disassembler incorrectly assumes that function
parameters are included in the locals and only locals beyond the
(optional) initial number of parameters should be counted. After making
the adjustment to ignore the parameters when disassembling locals, the
following is reported in the disassembly which is consistent with the
number (and names) of the locals in the source map and with the types of
the locals in the trace:
```
L0: %#7: u64
L1: %#8: u64
L2: __match_tmp%#match_subject#2#2#0: &SomeEnum
L3: __match_tmp%#unpack_subject#1#1#0: SomeEnum
L4: field#3#0: u64
L5: res#1#0: u64
```
## Test plan
All tests should pass
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The fastpay client was managing a single account associated with an address. Fastnft has instead a notion of objects, many of which may be associated with a client. We need to refactor the core client logic, the networked client logic, as well as their tests to build a client that handles many objects and can act on them.
The text was updated successfully, but these errors were encountered: