Migrate to Cairo 2.1.0

[tarrencev]

Resolves #559 #664

[tarrencev]

@kariy need to update this

[shramee]

@tarrencev @kariy

Updates

1. rust-fmt
2. Return when the target path doesn't exists
3. Pass vec[packages] to scarb::ops::compile
   • This is fixed for all scarb::ops::compile calls in dojo.

Now it's building, but 2 tests are failing,

1. test_component: class hash mismatch

thread 'contract::component::test::test_component' panicked at 
  assertion failed: `(left == right)`
   left: `FieldElement { inner: 0x02da8fb6056624dd6fa7070497350a13914a21e2a53f171271f72721c5448912 }`,
   right: `FieldElement { inner: 0x042e9aac8d3d6e6185815f891a5fa3b442e86e2bef3bca3ac620744309af7fe7 }`,
in crates/dojo-client/src/contract/component_test.rs:28:5

2. test_system: spawn.dependencies unwrap panic.

thread 'contract::system::test::test_system' panicked at
  called `Result::unwrap()` on an `Err` value:
    ReaderError(ContractReaderError(ProviderError(StarknetError(ContractError)))),
in crates/dojo-client/src/contract/system_test.rs:27:59

[tarrencev]

For failure 1, that is expected since the bytecode changed. We can update the expected class hash to match the new output

[kariy]

btw seems like the rust_fmt script is broken... because the fmt rules we're using are available only on nightly but we're using the stable channel. Which was changed when we pinned the rust ver in #643

cargo fmt --check --all -- "$@"

[shramee]

@tarrencev

For failure 1, that is expected since the bytecode changed. We can update the expected class hash to match the new output

Aye, after fixing that, it seems like schema entrypoint is missing from Component contract.

• Similar names replacement?

And dependencies is missing from System contract.

@kariy

btw seems like the rust_fmt script is broken...

Aah, perhaps I'm on nightly, it seemed to work for me.

[tarrencev]

Ah yes, we've removed the schema method for now. We should update the logic to not use it. It was a naive implantation anyways and assumed one slot per member

[shramee]

Edited the message above with newer deets. I'll catch up later!

[kariy]

@tarrencev whats the reason for removing the dependencies function for system? is it related to the removal of schema as well?

[tarrencev]

@tarrencev whats the reason for removing the dependencies function for system? is it related to the removal of schema as well?

The way that we were extracting dependencies was creating syntactical constraints, it's the reason we always needed to pass a struct constructor to set, so I removed it for now. We'll add it back in the future. schema was also half baked, i'll add it back with the new codegen soon