starkware-libs / cairo Goto Github PK

View Code? Open in Web Editor NEW

1.4K 17.0 429.0 138.45 MB

Cairo is the first Turing-complete language for creating provable programs for general computation.

License: Apache License 2.0

Rust 89.60% Cairo 10.00% TypeScript 0.30% Shell 0.10%

starknet zero-knowledge-proofs zkp computational-integrity cairo

cairo's People

Contributors

Stargazers

Watchers

Forkers

amanusk ben2077 gnurik149 shuimuliang llabori-venehsoftw manipulation44 xjonathanlei nanne007 yutakanna 0xyyy trustless-sockets nanderoo punk5736 jayhaizeizai sayman71 pinokey mfaulk fairhopeweb archebald-now cwkang1998 enitrat software-mansion-labs 19858889 dan-starkware godspower-eze profiinvestor u4iaq jorgeantonio21 xiangjiao9 shramee bbrandtom oboulant wdshin maciektr isgasho gaetbout kennedytedesco nodzcf sanurichgit cryalex683 nizhan0808 chefcryptx midnight72121 ozzicurester1980 omahs eqlabs behnaming gurxo putragilang2 chirag-bgh tangfi sayrarh andrew-fleming darlington02 web3-net remedcu succinctpaul evolveart shuaiguo0 tserg mykytazhuravlov kurdybanash alon-dotan-starkware tarrencev eikix celiktepemurat gmh5225 0xdfex ericnordelo trangnv genya-z antazoey clementcauffet edgarbarrantes bzbee42 knedelec antoshkaolenka aniketpr01 sethm-pate big-aaron countrycousin milancermak jamestark pet3ris tranhoaison tinoh9 tommychris2004 eitan-starkware amxx arielelp 0xalpharush limechain litouking rajeebkm leonard-pat torresotis mitchelloliver leonalzfo malkinmckenzie joneskeegan

cairo's Issues

bug: Compiler panics on array sum example when explicitly type annotated

Bug Report

Cairo version:

$ git rev-parse HEAD
03553bd52053dec7fbe49da9cd6c4679843c030a

Current behavior:

$ cd crates/compiler
$ cat array_sum.cairo
// Computes the sum of the memory elements at addresses:
//   arr + 0, arr + 1, ..., arr + (size - 1).
func array_sum(arr: felt*, size: felt) -> felt {
    if (size == 0) {
        return 0;
    }

    // size is not zero.
    let sum_of_rest = array_sum(arr=arr + 1, size=size - 1);
    return arr[0] + sum_of_rest;
}
$ cargo run array_sum.cairo
error: Missing token TerminalComma.
 --> array_sum.cairo:3:25
func array_sum(arr: felt*, size: felt) -> felt {
                        ^

error: Skipped tokens. Expected: parameter.
 --> array_sum.cairo:3:25
func array_sum(arr: felt*, size: felt) -> felt {
                        ^

error: Skipped tokens. Expected: parameter.
 --> array_sum.cairo:3:26
func array_sum(arr: felt*, size: felt) -> felt {
                         ^

error: Missing token TerminalSemicolon.
 --> array_sum.cairo:10:15
    return arr[0] + sum_of_rest;
              ^

error: Skipped tokens. Expected: statement.
 --> array_sum.cairo:10:15
    return arr[0] + sum_of_rest;
              ^

error: Skipped tokens. Expected: statement.
 --> array_sum.cairo:10:17
    return arr[0] + sum_of_rest;
                ^

error: Skipped tokens. Expected: statement.
 --> array_sum.cairo:10:19
    return arr[0] + sum_of_rest;
                  ^

error: Cannot assign to an immutable variable.
 --> array_sum.cairo:9:33
    let sum_of_rest = array_sum(arr=arr + 1, size=size - 1);
                                ^*********^

error: Cannot assign to an immutable variable.
 --> array_sum.cairo:9:46
    let sum_of_rest = array_sum(arr=arr + 1, size=size - 1);
                                             ^***********^

error: Unexpected argument type. Expected: "core::felt", found: "()".
 --> array_sum.cairo:9:33
    let sum_of_rest = array_sum(arr=arr + 1, size=size - 1);
                                ^*********^

error: Unexpected argument type. Expected: "core::felt", found: "()".
 --> array_sum.cairo:9:46
    let sum_of_rest = array_sum(arr=arr + 1, size=size - 1);
                                             ^***********^

error: Unexpected return type. Expected: "core::felt", found: "()".
 --> array_sum.cairo:3:48
func array_sum(arr: felt*, size: felt) -> felt {
                                               ^

error: Unreachable code
 --> array_sum.cairo:10:16
    return arr[0] + sum_of_rest;
               ^***************^

thread 'main' panicked at 'Internal compiler error: Found a reachable statement at the end of the function.', crates/sierra_generator/src/store_variables/mod.rs:328:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Associated backtrace (with RUST_BACKTRACE=full):

stack backtrace:
   0:     0x560317402380 - std::backtrace_rs::backtrace::libunwind::trace::h32eb3e08e874dd27
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
   1:     0x560317402380 - std::backtrace_rs::backtrace::trace_unsynchronized::haa3f451d27bc11a5
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x560317402380 - std::sys_common::backtrace::_print_fmt::h5b94a01bb4289bb5
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/sys_common/backtrace.rs:66:5
   3:     0x560317402380 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hb070b7fa7e3175df
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/sys_common/backtrace.rs:45:22
   4:     0x560317422e0e - core::fmt::write::hd5207aebbb9a86e9
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/core/src/fmt/mod.rs:1202:17
   5:     0x5603173ff895 - std::io::Write::write_fmt::h3bd699bbd129ab8a
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/io/mod.rs:1679:15
   6:     0x560317403a03 - std::sys_common::backtrace::_print::h7a21be552fdf58da
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/sys_common/backtrace.rs:48:5
   7:     0x560317403a03 - std::sys_common::backtrace::print::ha85c41fe4dd80b13
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/sys_common/backtrace.rs:35:9
   8:     0x560317403a03 - std::panicking::default_hook::{{closure}}::h04cca40023d0eeca
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/panicking.rs:295:22
   9:     0x5603174036ef - std::panicking::default_hook::haa3ca8c310ed5402
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/panicking.rs:314:9
  10:     0x5603174040aa - std::panicking::rust_panic_with_hook::h7b190ce1a948faac
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/panicking.rs:698:17
  11:     0x560317403f61 - std::panicking::begin_panic_handler::{{closure}}::hbafbfdc3e1b97f68
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/panicking.rs:586:13
  12:     0x56031740282c - std::sys_common::backtrace::__rust_end_short_backtrace::hda93e5fef243b4c0
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/sys_common/backtrace.rs:138:18
  13:     0x560317403cc2 - rust_begin_unwind
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/panicking.rs:584:5
  14:     0x5603161980e3 - core::panicking::panic_fmt::h8d17ca1073d9a733
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/core/src/panicking.rs:142:14
  15:     0x56031622abc8 - sierra_generator::store_variables::AddStoreVariableStatements::finalize::h36830de016f3296d
                               at /home/jmcph4/dev/tmp/cairo/crates/sierra_generator/src/store_variables/mod.rs:328:9
  16:     0x56031622887c - sierra_generator::store_variables::add_store_statements::he4ad188b682d1664
                               at /home/jmcph4/dev/tmp/cairo/crates/sierra_generator/src/store_variables/mod.rs:51:5
  17:     0x5603162121ab - sierra_generator::function_generator::get_function_code::h2a73143ec4958829
                               at /home/jmcph4/dev/tmp/cairo/crates/sierra_generator/src/function_generator.rs:117:22
  18:     0x560316210d3f - sierra_generator::function_generator::priv_free_function_sierra_data::hab5f8418368d5818
                               at /home/jmcph4/dev/tmp/cairo/crates/sierra_generator/src/function_generator.rs:46:20
  19:     0x5603161d80c7 - <sierra_generator::db::PrivFreeFunctionSierraDataQuery as salsa::plumbing::QueryFunction>::execute::hc6d66b60052cef2f
                               at /home/jmcph4/dev/tmp/cairo/crates/sierra_generator/src/db.rs:60:21
  20:     0x56031629fe94 - salsa::derived::slot::Slot<Q,MP>::read_upgrade::{{closure}}::h0b8cba695b7e60d8
                               at /home/jmcph4/.cargo/registry/src/github.com-1ecc6299db9ec823/salsa-0.16.1/src/derived/slot.rs:218:13
  21:     0x5603163a4843 - salsa::runtime::Runtime::execute_query_implementation::h1a50a80a72e907c2
                               at /home/jmcph4/.cargo/registry/src/github.com-1ecc6299db9ec823/salsa-0.16.1/src/runtime.rs:330:21
  22:     0x560316294d84 - salsa::derived::slot::Slot<Q,MP>::read_upgrade::he5d05cf2c1d00fc4
                               at /home/jmcph4/.cargo/registry/src/github.com-1ecc6299db9ec823/salsa-0.16.1/src/derived/slot.rs:215:26
  23:     0x5603162b63be - salsa::derived::slot::Slot<Q,MP>::read::he126cfc7920fc701
                               at /home/jmcph4/.cargo/registry/src/github.com-1ecc6299db9ec823/salsa-0.16.1/src/derived/slot.rs:148:9
  24:     0x56031620cfb6 - <salsa::derived::DerivedStorage<Q,MP> as salsa::plumbing::QueryStorageOps<Q>>::try_fetch::ha5feccfb396f28a8
                               at /home/jmcph4/.cargo/registry/src/github.com-1ecc6299db9ec823/salsa-0.16.1/src/derived.rs:170:13
  25:     0x56031631d6c0 - salsa::QueryTable<Q>::try_get::h02162e58e862b34e
                               at /home/jmcph4/.cargo/registry/src/github.com-1ecc6299db9ec823/salsa-0.16.1/src/lib.rs:494:9
  26:     0x56031631ca9d - salsa::QueryTable<Q>::get::hce4ec1bd18bbcce4
                               at /home/jmcph4/.cargo/registry/src/github.com-1ecc6299db9ec823/salsa-0.16.1/src/lib.rs:490:9
  27:     0x5603161d7be8 - <DB as sierra_generator::db::SierraGenGroup>::priv_free_function_sierra_data::__shim::h5dcf5fb671026d42
                               at /home/jmcph4/dev/tmp/cairo/crates/sierra_generator/src/db.rs:17:1
  28:     0x5603161ae00c - <DB as sierra_generator::db::SierraGenGroup>::priv_free_function_sierra_data::h9e43f56a777470dd
                               at /home/jmcph4/dev/tmp/cairo/crates/sierra_generator/src/db.rs:17:1
  29:     0x560316210e66 - sierra_generator::function_generator::free_function_sierra_diagnostics::hca8725a3375acae6
                               at /home/jmcph4/dev/tmp/cairo/crates/sierra_generator/src/function_generator.rs:55:5
  30:     0x5603161d8107 - <sierra_generator::db::FreeFunctionSierraDiagnosticsQuery as salsa::plumbing::QueryFunction>::execute::h7fdc4251641c77f0
                               at /home/jmcph4/dev/tmp/cairo/crates/sierra_generator/src/db.rs:66:21
  31:     0x5603162a0194 - salsa::derived::slot::Slot<Q,MP>::read_upgrade::{{closure}}::h1f8e389682b06d1d
                               at /home/jmcph4/.cargo/registry/src/github.com-1ecc6299db9ec823/salsa-0.16.1/src/derived/slot.rs:218:13
  32:     0x5603163a6d3d - salsa::runtime::Runtime::execute_query_implementation::hed52ac40314a984b
                               at /home/jmcph4/.cargo/registry/src/github.com-1ecc6299db9ec823/salsa-0.16.1/src/runtime.rs:330:21
  33:     0x56031628f284 - salsa::derived::slot::Slot<Q,MP>::read_upgrade::h4b669f88ed88cc74
                               at /home/jmcph4/.cargo/registry/src/github.com-1ecc6299db9ec823/salsa-0.16.1/src/derived/slot.rs:215:26
  34:     0x5603162b4cae - salsa::derived::slot::Slot<Q,MP>::read::h3c078c58994ce3d5
                               at /home/jmcph4/.cargo/registry/src/github.com-1ecc6299db9ec823/salsa-0.16.1/src/derived/slot.rs:148:9
  35:     0x56031620d416 - <salsa::derived::DerivedStorage<Q,MP> as salsa::plumbing::QueryStorageOps<Q>>::try_fetch::ha62f559d745d2030
                               at /home/jmcph4/.cargo/registry/src/github.com-1ecc6299db9ec823/salsa-0.16.1/src/derived.rs:170:13
  36:     0x56031631de50 - salsa::QueryTable<Q>::try_get::hf37c28b8634befb1
                               at /home/jmcph4/.cargo/registry/src/github.com-1ecc6299db9ec823/salsa-0.16.1/src/lib.rs:494:9
  37:     0x56031631c82d - salsa::QueryTable<Q>::get::h9192b951c414353d
                               at /home/jmcph4/.cargo/registry/src/github.com-1ecc6299db9ec823/salsa-0.16.1/src/lib.rs:490:9
  38:     0x5603161d7c38 - <DB as sierra_generator::db::SierraGenGroup>::free_function_sierra_diagnostics::__shim::h3e405fbdf25d093d
                               at /home/jmcph4/dev/tmp/cairo/crates/sierra_generator/src/db.rs:17:1
  39:     0x5603161ae09c - <DB as sierra_generator::db::SierraGenGroup>::free_function_sierra_diagnostics::h5ef51ac8d989fde2
                               at /home/jmcph4/dev/tmp/cairo/crates/sierra_generator/src/db.rs:17:1
  40:     0x56031622cb30 - sierra_generator::program_generator::module_sierra_diagnostics::hf9863b321974fdd3
                               at /home/jmcph4/dev/tmp/cairo/crates/sierra_generator/src/program_generator.rs:33:28
  41:     0x5603161d818b - <sierra_generator::db::ModuleSierraDiagnosticsQuery as salsa::plumbing::QueryFunction>::execute::h153e91909670ee61
                               at /home/jmcph4/dev/tmp/cairo/crates/sierra_generator/src/db.rs:79:21
  42:     0x5603162a001c - salsa::derived::slot::Slot<Q,MP>::read_upgrade::{{closure}}::h118641dd7401ca59
                               at /home/jmcph4/.cargo/registry/src/github.com-1ecc6299db9ec823/salsa-0.16.1/src/derived/slot.rs:218:13
  43:     0x5603163a3dbd - salsa::runtime::Runtime::execute_query_implementation::h102ccec7e02cef40
                               at /home/jmcph4/.cargo/registry/src/github.com-1ecc6299db9ec823/salsa-0.16.1/src/runtime.rs:330:21
  44:     0x56031628b5f4 - salsa::derived::slot::Slot<Q,MP>::read_upgrade::h0b9b85c36c7e708d
                               at /home/jmcph4/.cargo/registry/src/github.com-1ecc6299db9ec823/salsa-0.16.1/src/derived/slot.rs:215:26
  45:     0x5603162b51ce - salsa::derived::slot::Slot<Q,MP>::read::h407ed6dbe63327be
                               at /home/jmcph4/.cargo/registry/src/github.com-1ecc6299db9ec823/salsa-0.16.1/src/derived/slot.rs:148:9
  46:     0x56031620c706 - <salsa::derived::DerivedStorage<Q,MP> as salsa::plumbing::QueryStorageOps<Q>>::try_fetch::h8c715258687fce62
                               at /home/jmcph4/.cargo/registry/src/github.com-1ecc6299db9ec823/salsa-0.16.1/src/derived.rs:170:13
  47:     0x56031631dc04 - salsa::QueryTable<Q>::try_get::h9d480919a2d9445b
                               at /home/jmcph4/.cargo/registry/src/github.com-1ecc6299db9ec823/salsa-0.16.1/src/lib.rs:494:9
  48:     0x56031631c603 - salsa::QueryTable<Q>::get::h1f3c4b77b56503e0
                               at /home/jmcph4/.cargo/registry/src/github.com-1ecc6299db9ec823/salsa-0.16.1/src/lib.rs:490:9
  49:     0x5603161d7ce4 - <DB as sierra_generator::db::SierraGenGroup>::module_sierra_diagnostics::__shim::h3ef25b97d78e2cdf
                               at /home/jmcph4/dev/tmp/cairo/crates/sierra_generator/src/db.rs:17:1
  50:     0x5603161adf42 - <DB as sierra_generator::db::SierraGenGroup>::module_sierra_diagnostics::h1706dfefce595862
                               at /home/jmcph4/dev/tmp/cairo/crates/sierra_generator/src/db.rs:17:1
  51:     0x5603161aa88b - compiler::diagnostics::check_diagnostics::hc74fb0900de38cf3
                               at /home/jmcph4/dev/tmp/cairo/crates/compiler/src/diagnostics.rs:60:24
  52:     0x5603161a8ec6 - compiler::compile_prepared_db::ha89fb24f3e57441d
                               at /home/jmcph4/dev/tmp/cairo/crates/compiler/src/lib.rs:59:8
  53:     0x5603161a8d07 - compiler::compile_cairo_project_at_path::h1aa28e8a77278bce
                               at /home/jmcph4/dev/tmp/cairo/crates/compiler/src/lib.rs:40:5
  54:     0x5603161a12db - cairo_compile::main::haedc1ec288c31474
                               at /home/jmcph4/dev/tmp/cairo/crates/compiler/src/cli.rs:29:26
  55:     0x5603161a7d9b - core::ops::function::FnOnce::call_once::h15414a5ab5a4753a
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/core/src/ops/function.rs:248:5
  56:     0x56031619ac0e - std::sys_common::backtrace::__rust_begin_short_backtrace::hc44b5c73dd4080c9
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/sys_common/backtrace.rs:122:18
  57:     0x5603161a5651 - std::rt::lang_start::{{closure}}::h9adda850af949275
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/rt.rs:166:18
  58:     0x5603173fb52f - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::hb69be6e0857c6cfb
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/core/src/ops/function.rs:283:13
  59:     0x5603173fb52f - std::panicking::try::do_call::h396dfc441ee9c786
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/panicking.rs:492:40
  60:     0x5603173fb52f - std::panicking::try::h6cdda972d28b3a4f
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/panicking.rs:456:19
  61:     0x5603173fb52f - std::panic::catch_unwind::h376039ec264e8ef9
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/panic.rs:137:14
  62:     0x5603173fb52f - std::rt::lang_start_internal::{{closure}}::hc94720ca3d4cb727
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/rt.rs:148:48
  63:     0x5603173fb52f - std::panicking::try::do_call::h2422fb95933fa2d5
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/panicking.rs:492:40
  64:     0x5603173fb52f - std::panicking::try::h488286b5ec8333ff
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/panicking.rs:456:19
  65:     0x5603173fb52f - std::panic::catch_unwind::h81636549836d2a25
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/panic.rs:137:14
  66:     0x5603173fb52f - std::rt::lang_start_internal::h6ba1bb743c1e9df9
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/rt.rs:148:20
  67:     0x5603161a562a - std::rt::lang_start::hcdb1452c5a420608
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/rt.rs:165:17
  68:     0x5603161a2981 - main
  69:     0x7fbf0f946d0a - __libc_start_main
                               at ./csu/../csu/libc-start.c:308:16
  70:     0x5603161983ba - _start
  71:                0x0 - <unknown>

Expected behavior:

For the compiler to not panic.

Steps to reproduce:

See above.

Related code:

The site of the direct panic is:

cairo/crates/sierra_generator/src/store_variables/mod.rs

Lines 328 to 331 in 03553bd

 assert!( 

 self.state_opt.is_none(), 

 "Internal compiler error: Found a reachable statement at the end of the function." 

 );

Other information:

Notably, this version of the code does not induce a panic in the compiler:

3c3
< func array_sum(arr: felt*, size: felt) -> felt {
---
> func array_sum(arr: felt*, size) -> felt {

$ cargo run safe_array_sum.cairo
error: Missing token TerminalComma.
 --> safe_array_sum.cairo:3:25
func array_sum(arr: felt*, size) -> felt {
                        ^

error: Skipped tokens. Expected: parameter.
 --> safe_array_sum.cairo:3:25
func array_sum(arr: felt*, size) -> felt {
                        ^

error: Skipped tokens. Expected: parameter.
 --> safe_array_sum.cairo:3:26
func array_sum(arr: felt*, size) -> felt {
                         ^

error: Missing tokens. Expected a type clause.
 --> safe_array_sum.cairo:3:32
func array_sum(arr: felt*, size) -> felt {
                               ^

error: Missing token TerminalSemicolon.
 --> safe_array_sum.cairo:10:15
    return arr[0] + sum_of_rest;
              ^

error: Skipped tokens. Expected: statement.
 --> safe_array_sum.cairo:10:15
    return arr[0] + sum_of_rest;
              ^

error: Skipped tokens. Expected: statement.
 --> safe_array_sum.cairo:10:17
    return arr[0] + sum_of_rest;
                ^

error: Skipped tokens. Expected: statement.
 --> safe_array_sum.cairo:10:19
    return arr[0] + sum_of_rest;
                  ^

error: Unknown type.
 --> safe_array_sum.cairo:3:32
func array_sum(arr: felt*, size) -> felt {
                               ^

error: Binary operator '==' is not supported for types '<missing>' and 'core::felt'.
 --> safe_array_sum.cairo:4:14
    if (size == 0) {
             ^^

error: Cannot assign to an immutable variable.
 --> safe_array_sum.cairo:9:33
    let sum_of_rest = array_sum(arr=arr + 1, size=size - 1);
                                ^*********^

error: Binary operator '-' is not supported for types '<missing>' and 'core::felt'.
 --> safe_array_sum.cairo:9:56
    let sum_of_rest = array_sum(arr=arr + 1, size=size - 1);
                                                       ^

error: Cannot assign to an immutable variable.
 --> safe_array_sum.cairo:9:46
    let sum_of_rest = array_sum(arr=arr + 1, size=size - 1);
                                             ^***********^

error: Unexpected argument type. Expected: "core::felt", found: "()".
 --> safe_array_sum.cairo:9:33
    let sum_of_rest = array_sum(arr=arr + 1, size=size - 1);
                                ^*********^

error: Unexpected argument type. Expected: "<missing>", found: "()".
 --> safe_array_sum.cairo:9:46
    let sum_of_rest = array_sum(arr=arr + 1, size=size - 1);
                                             ^***********^

error: Unexpected return type. Expected: "core::felt", found: "()".
 --> safe_array_sum.cairo:3:42
func array_sum(arr: felt*, size) -> felt {
                                         ^

Error: Compilation failed.

feat: Local Proof Generator & Verifier

Feature Request

Wish to have a local proof to understand the zk-proof and develop in some local/offline project(such as using bluetooth to transfer zk-proof)

Describe Preferred Solution

A compile option to generate proof json and a verifier to verify the json

Describe Alternatives

Related Code

Additional Context

If the feature request is approved, would you be willing to submit a PR?
(Help can be provided if you need assistance submitting a PR)

[Y ] Yes
No

feat: PartialEq for ContractAddress

Feature Request

ContractAddress should implement PartialEq so we are able to do this:

let f = contract_address_const::<0>();
let g = contract_address_const::<0>();
assert(f == g, 'no');

The feature has already been mentioned/suggested in #2171.

If the feature request is approved, would you be willing to submit a PR?
(Help can be provided if you need assistance submitting a PR)

dev: improve error message for namespace collision with storage variables

In the ERC20 example, if we rename get_name() function to name(), the following error is thrown:

error: The name `name` is defined multiple times.
 --> contract:108:5
    mod name {
    ^********^

error: Expected function, found module.
 --> contract:376:23
            let res = super::name();
                      ^*********^

Error: Compilation failed.

However, the error message is not immediately clear as to what the issue is as the code snippets displayed are not in the contract. It will be helpful to point to the Storage struct instead.

bug: `should_panic` does not work in some cases

Bug Report

Cairo version:

Commit: 775dded

Current behavior:

should_panic does not work if a panic is triggered by a call. when a call to a function panics in a test then the test fails (actually it fails badly, not a failing test, the test panic) even when adding should_panic.

Expected behavior:

Test should pass and not fail badly.
Related code:

#[test]
#[should_panic]
fn reproduce_bug() {
    trigger_panic();
}

fn trigger_panic() {
    let mut data = array_new::<Array::<u128>>();
    let len = array_len::<Array::<u128>>(data);
}

bug: update command line in installing vscode-cairo

Bug Report

Cairo version:

Release v1.0.0-alpha.2

Steps to reproduce:

run sudo npm install -g vsce in terminal

display:

npm WARN deprecated [email protected]: vsce has been renamed to @vscode/vsce. Install using @vscode/vsce instead.

Panicked at 'called `Result::unwrap()` on an `Err` value: UnknownType'

Bug Report

This happens in try_get_core_ty_by_name() located in file cairo-lang-semantic/src/corelib.rs
UnknownType Error looks a bit confusing, which probably refers to Cairo types. And usually just needs to have cairo-libs added to the project. This might not be fixed in favour of #1595 solution but just putting it here to have some searchability...

Cairo version:

18b55fe

Current behavior:

Rather unhelpful error 'Panicked at 'called Result::unwrap() on an Err value: UnknownType'.

Expected behavior:

Maybe something helpful indicating corelib is missing?

Steps to reproduce:

Add cairo as dependency and try to something that involves compiling Cairo.

Related code:

Other information:

bug: event emit gives `error: Variable was previously moved.`

Bug Report

Cairo version:

b51c511ab39dae631362d4157853db46c2c49d64

Current behavior:

emitting the following event:

    #[event]
    fn ComponentValueSet(component_id: felt, entity_id: felt, data: Array::<felt>) {}

    ...

    #[external]
    fn on_component_set(entity_id: felt, data: Array::<felt>) {
        ComponentValueSet(caller_address_felt, entity_id, data);
    }

results in the error

error: Variable was previously moved.
 --> contract:143:9
        serde::Serde::<felt>::serialize(ref data, entity_id);
        ^**************************************************^

compiled contract looks like:

    #[event]
    fn ComponentValueSet(component_id: felt, entity_id: felt, data: Array::<felt>) {
        let mut keys = array_new();
        array_append(ref keys, 0x20427dbf22fa80ffee4e42a5864b7fd37b9f906cc4db230d084faa3a0ce558f);
        let mut data = array_new();
        serde::Serde::<felt>::serialize(ref data, component_id);
        serde::Serde::<felt>::serialize(ref data, entity_id);
        serde::Serde::<Array::<felt>>::serialize(ref data, data);
        
        starknet::emit_event_syscall(keys, data).unwrap_syscall()
    }

full repo at: dojoengine/dojo#51

feat: allow formatter to format stdin

Feature Request

Describe the Feature Request

Currently the formatter only takes file paths as input. Would be nice if it can take stdin as input when the argument is -. This is useful in editors, which usually interface with formatters via stdin/stdout.

Describe Preferred Solution

Read from stdin when the supplied argument is -.

Describe Alternatives

N/A

Related Code

N/A

Additional Context

N/A

If the feature request is approved, would you be willing to submit a PR?
(Help can be provided if you need assistance submitting a PR)

bug: files with syntax error incorrectly reported as well-formatted

Bug Report

Cairo version:

Using the current main at 5435626.

Steps to reproduce:

Create an empty folder containing only an unparseable cairo file. Then try to run a formatter check:

$ mkdir fmt_test && cd fmt_test
$ echo "asdf" > file.cairo
$ formatter_cli --check
$ echo $?

Current behavior:

The formatter does indeed report an error regarding the issue: A parsing error occurred in file: ./file.cairo. The file was not formatted.

However, the exit code is 0, indicating a success:

$ echo $?
0

This would cause CI workflows to give false negative on format errors, since CI workflows would only check the exit code. Editors would also interpret the result as successful and replace file content with the error message.

Expected behavior:

The exit code should be non-zero.

Related code:

This is what's causing the false negative.

cairo/crates/formatter/src/bin/cli.rs

Lines 26 to 33 in 5435626

 if !diagnostics.0.leaves.is_empty() { 

 eprintln!( 

 "{}", 

 format!("A parsing error occurred in file: {file_path}. The file was not formatted.") 

 .red() 

 ); 

 return true; 

 }

Other information:

N/A

bug: calling `array_len` on a 2d array crashes the Cairo program

Bug Report

Cairo version:

Commit: 775dded

Current behavior:

Calling array_len on a 2d array crashes the Cairo program.

Expected behavior:

array_len should not crash and return correct value.

Steps to reproduce:

Create a 2d array
Call array_len

Related code:

let mut data = array_new::<Array::<u128>>();
let len = array_len::<Array::<u128>>(data);

Other information:

Crash output:

thread 'main' panicked at 'Failed assertion Some(Known(0)) == Some(Known(2)) for iteration 0', /Users/abdel/.cargo/registry/src/github.com-1ecc6299db9ec823/itertools-0.10.5/src/lib.rs:3709:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

bug: calldata parameter name result in failed starknet compilation when using dispatcher

The following diff:

diff --git a/crates/cairo-lang-starknet/test_data/test_contract.cairo b/crates/cairo-lang-starknet/test_data/test_contract.cairo
index 3ddc761e..f7443ee9 100644
--- a/crates/cairo-lang-starknet/test_data/test_contract.cairo
+++ b/crates/cairo-lang-starknet/test_data/test_contract.cairo
@@ -1,6 +1,6 @@
 #[abi]
 trait IAnotherContract {
-    fn foo(a: u128) -> u128;
+    fn foo(calldata: u128) -> u128;
 }
 
 
@@ -25,9 +25,9 @@ mod TestContract {
     fn empty() {}
 
     #[external]
-    fn call_foo(a: u128) -> u128 {
+    fn call_foo(calldata: u128) -> u128 {
         // TODO(ilya): pass the address of foo as an argument.
         let foo_address = starknet::contract_address_const::<17>();
-        super::IAnotherContractDispatcher::foo(foo_address, a)
+        super::IAnotherContractDispatcher::foo(foo_address, calldata)
     }
 }

Results in an error like:

error: Plugin diagnostic: Unexpected argument type. Expected: "core::integer::u128", found: "core::array::Array::<core::felt>".
 --> test_contract.cairo:3:12
    fn foo(calldata: u128) -> u128;
           ^******^

Error: failed to compile: lib

I think it would be better not to "reserve" the calldata param? I think the cause is call_contract_syscall? Maybe the compiler can namespace it.

bug: LSP formatting doesn't work for Helix

Bug Report

Cairo version:

main head at a621d15

Steps to reproduce:

First install the language server:

$ cargo install --locked --path crates/languageserver

In the Helix editor, set the language server of Cairo:

name = "cairo"
language-server = { command = "languageserver" }

Then open some unformatted Cairo file and try to format the file.

Current behavior:

The file does not change.

Expected behavior:

The file changes to the formatted text.

Related code:

Pretty sure this is causing the issue:

cairo/crates/languageserver/src/lib.rs

Lines 320 to 326 in a621d15

 Ok(Some(vec![TextEdit { 

 range: Range { 

 start: Position { line: 0, character: 0 }, 

 end: Position { line: u32::MAX, character: 0 }, 

 }, 

 new_text, 

 }]))

Other information:

N/A

feat: StorageAccess on all core integer types

Feature Request

All core integer types should have StorageAccess implemented so we can use them in our Starknet Storage struct. Currently (9bc2c58), only u8 and u128 are supported.

Related Code

#[contract]
mod Foo {
    struct Storage {
        s1: u16,
        s2: u32,
        s3: u64,
        s4: usize
    }

    #[constructor]
    fn constructor() {
        s1::write(1_u16);
        s2::write(2_u32);
        s3::write(3_u64);
        s4::write(4_usize);
    }
}

Compiling this contract results in the following errors:

error: Trait `core::starknet::storage_access::StorageAccess::<core::integer::u16>` has no implementation in the context.
 --> contract:25:13
            starknet::StorageAccess::<u16>::read(
            ^***********************************^

error: Trait `core::starknet::storage_access::StorageAccess::<core::integer::u16>` has no implementation in the context.
 --> contract:33:13
            starknet::StorageAccess::<u16>::write(
            ^************************************^

error: Trait `core::starknet::storage_access::StorageAccess::<core::integer::u32>` has no implementation in the context.
 --> contract:50:13
            starknet::StorageAccess::<u32>::read(
            ^***********************************^

error: Trait `core::starknet::storage_access::StorageAccess::<core::integer::u32>` has no implementation in the context.
 --> contract:58:13
            starknet::StorageAccess::<u32>::write(
            ^************************************^

error: Trait `core::starknet::storage_access::StorageAccess::<core::integer::u64>` has no implementation in the context.
 --> contract:75:13
            starknet::StorageAccess::<u64>::read(
            ^***********************************^

error: Trait `core::starknet::storage_access::StorageAccess::<core::integer::u64>` has no implementation in the context.
 --> contract:83:13
            starknet::StorageAccess::<u64>::write(
            ^************************************^

error: Trait `core::starknet::storage_access::StorageAccess::<core::integer::u32>` has no implementation in the context.
 --> contract:100:13
            starknet::StorageAccess::<usize>::read(
            ^*************************************^

error: Trait `core::starknet::storage_access::StorageAccess::<core::integer::u32>` has no implementation in the context.
 --> contract:108:13
            starknet::StorageAccess::<usize>::write(
            ^**************************************^

Error: Compilation failed.

If the feature request is approved, would you be willing to submit a PR?
(Help can be provided if you need assistance submitting a PR)

feat: Generic impl parameters

Have generic parameters that can hold impls, for example:

fn foo<T, impl Drop<T>> (x: T) {
}

This is a kind of a constraint on T. An instantiator would have to pass a Drop impl for T (a proof it is droppable), or let the compiler infer it by finding an applicable impl at the context.

Without this feature, it is hard to write non-trivial generic code.

dev: remove turbofish syntax

8e0293c

We can now declare types without the turbofish syntax. This is a great improvement for readability

bug: wrapping array results in `Failed to specialize:`

Bug Report

Cairo version:

alpha2

Current behavior:

I'm attempting to wrap an array and run a simple test as shown below. Not sure what im doing wrong but the simple test results in

thread 'main' panicked at 'Failed to specialize: `dup<query::query::Query::<core::felt>>`'

use array::ArrayTrait;

struct Query<T> {
    data: Array::<T>,
}

trait QueryTrait<T> {
    fn new() -> Query::<T>;
    fn append(ref self: Query::<T>, value: T);
}

impl QueryImpl<T> of QueryTrait::<T> {
    #[inline(always)]
    fn new() -> Query::<T> {
        Query {
            data: ArrayTrait::new(),
        }
    }
    fn append(ref self: Query::<T>, value: T) {
        let mut data = self.data;
        array_append(ref data, value)
    }
}

impl QueryDrop of Drop::<Query::<felt>>;

#[test]
fn test_query() {
    let mut query = QueryTrait::<felt>::new();
    query.append(1);
}

Expected behavior:

Should successfully append a value

bug: Constants over revocations

This code fails:

#[test]
fn test_bug_test() {
    let a = 1;
    let b = 2;
    let mut c = 0;
    if a < b {
        c = LegacyHash::hash(a, b);
    } else {
        c = LegacyHash::hash(b, a);
    }
}

Document Description Inaccurate

Description Inaccurate Report

Related Document

/crates/runner/Readme.md

Description Inaccurate

It seems that exmaple in "with gas" is actually a without gas version while "without gas" is a with gas version

dev: generics type syntax contains turbofish

fn main() -> Option::<felt> {
    fib(1, 1, 13)
}

/// Calculates fib...
fn fib(a: felt, b: felt, n: felt) -> Option::<felt> {
    get_gas()?;
    match n {
        0 => Option::<felt>::Some(a),
        _ => fib(b, a + b, n - 1),
    }
}

I hate to bikeshed but the syntax looks weird with turbofish in type signatures. (Turbofish are expected in expressions though so that part’s fine.) Could it be changed to this for consistency with Rust:

fn main() -> Option<felt> {
    fib(1, 1, 13)
}

/// Calculates fib...
fn fib(a: felt, b: felt, n: felt) -> Option<felt> {
    get_gas()?;
    match n {
        0 => Option::<felt>::Some(a),
        _ => fib(b, a + b, n - 1),
    }
}

thank you

bug: Structure referencing itself

Bug Report

Cairo version:

Tested at: eaa1153

Current behavior:

Trying to run this code:

// Core lib imports
use option::OptionTrait;
use box::Box;

#[derive(Drop)]
struct Node {
    value: felt,
    left: Option::<Box::<Node>>,
}

// impl NodeDrop of Drop::<Node>;
impl BoxNodeDrop of Drop::<Box::<Node>>;
impl OptionBoxNodeDrop of Drop::<Option::<Box::<Node>>>;

#[test]
#[available_gas(2000000)]
fn simple_test() {
    let bst = Node {
            value :12, 
            left: Option::None(()),
        };
        
    assert(bst.value == 12, 'value should be 12');
    // assert(bst.left.is_none(), 'left should be none');

}

I run into:
thread 'main' panicked at 'Internal error, cycle detected:
And if I uncomment the last assertion, I run into:
error: Variable was previously moved.

Expected behavior:

It should be possible to create such structure.

Related commits:
3ef87ab
7400dc5

feat: How To Install paragraph in the readme

Feature Request

Readme file should have How To Install section.

bug: error when compiling `starknet-compile`

Bug Report

Cairo version:

HEAD

Current behavior:

Compiling starknet-compile outputs errors:

cargo run --bin starknet-compile crates/cairo-lang-starknet/test_data/hello_starknet.cairo
   Compiling cairo-lang-sierra v0.1.0 (/Users/tarrence/code/cairo/crates/cairo-lang-sierra)
   Compiling cairo-lang-semantic v0.1.0 (/Users/tarrence/code/cairo/crates/cairo-lang-semantic)
   Compiling cairo-lang-casm v0.1.0 (/Users/tarrence/code/cairo/crates/cairo-lang-casm)
error: there is no argument named `dict_manager_ptr`
   --> crates/cairo-lang-casm/src/hints/mod.rs:189:21
    |
189 | /                     "
190 | |
191 | |                         if '__dict_manager' not in globals():
192 | |                             from starkware.cairo.common.dict import DictManager
...   |
200 | |                         )
201 | |                 "
    | |_________________^
    |
    = note: did you intend to capture a variable `dict_manager_ptr` from the surrounding scope?
    = note: to avoid ambiguity, `format_args!` cannot capture variables when the format string is expanded from a macro

bug: Crash when trying to make '==' with two into()

Bug Report

Cairo version:

Tried at commit f030973

Current behavior:
While trying to:
assert(contract_address1.into() == contract_address2.into(), 'Some message');

Makes me crash into:
thread 'main' panicked at 'Types should be fully resolved at this point.'

But if I do:
assert(contract_address1.into() == contract_address_to_felt(contract_address1), 'Some message');

It works, as the left side knows it should transform into the felt type to comply with the right side

Expected behavior:

It shouldn't complain and resolve a common type they both can agree on.

Other information:

Maybe ContractAddress should implement the PartialEq and Eq trait to not have to perform this operation.
But still it should be fixed

bug: cairo-lang-casm cannot be used as an external crate

Bug Report

Cairo version:

v.0.1.0

Current behavior:

cairo-lang-casm and other crates depending on cairo-vm cannot be used as external crates in other projects.

Expected behavior:

cairo-lang-casm and other crates depending on cairo-vm can be used as external crates.

Steps to reproduce:

cairo-vm 0.1.1 is a breaking change, the issue and the steps to reproduce have been described in lambdaclass/cairo-vm#730

For example:

cargo new --lib example
cd example/
cargo add cairo-lang-starknet
cargo check

Cargo check fails.

Related code:

Other information:

I imagine this has to be fixed either on cairo's side by further restricting the dependency to =0.1.0 or on cairo-vm's side by yanking the release and re-releasing as 0.2.0.

bug: unsupported match arm

Bug Report

Cairo version:

Latest

Current behavior:

Invalid match arm match rounding

Expected behavior:

Should compile

Steps to reproduce:

Full reproduction is here: https://github.com/auditless/cairo-erc4626/pull/20/files

Related code:

#[derive(Copy, Drop, PartialEq, Eq)]
enum Rounding {
    Down: (), // Toward negative infinity
    Up: (), // Toward infinity
    Zero: (), // Toward zero
}

fn is_up(rounding: Rounding) -> bool {
    match rounding {
        Rounding::Up(_) => true,
        Rounding::Down(_) => false,
        Rounding::Zero(_) => false,
    }
}

Other information:

bug: `Failed to specialize: `drop<dojo::query::Query::<core::felt>>`

Bug Report

Cairo version:

0346859

Current behavior:

use dict::DictFeltToTrait;

struct Query<T> {
    data: DictFeltTo::<T>, 
}

trait QueryTrait<T> {
    fn new() -> Query::<T>;
}

impl QueryImpl<T> of QueryTrait::<T> {
    #[inline(always)]
    fn new() -> Query::<T> {
        query_new()
    }
}

fn query_new<T>() -> Query::<T> {
    let mut dict = DictFeltToTrait::<T>::new();
    Query::<T> { data: dict }
}

impl QueryFeltDrop of Drop::<Query::<felt>>;
impl DictFeltToDrop of Drop::<DictFeltTo::<felt>>;

#[test]
fn test_query() {
    let mut query = QueryTrait::<felt>::new();
}

results in

thread 'main' panicked at 'Failed to specialize: `drop<dojo::query::Query::<core::felt>>`', crates/cairo-lang-sierra-generator/src/utils.rs:213:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

@spapinistarkware I know you mentioned adding a destroy method and squashing the dict previously. I've been unable to get that to compile either. Please let me know if there is something I am missing?

for example:

use dict::DictFeltToTrait;

struct Query<T> {
    data: DictFeltTo::<T>, 
}

trait QueryTrait<T> {
    fn new() -> Query::<T>;
    fn destroy(self: Query::<T>);
}

impl QueryImpl<T> of QueryTrait::<T> {
    #[inline(always)]
    fn new() -> Query::<T> {
        query_new()
    }

    fn destroy(self: Query::<T>) {
        let mut data = self.data;
        data.squash();
    }
}

fn query_new<T>() -> Query::<T> {
    let mut dict = DictFeltToTrait::<T>::new();
    Query::<T> { data: dict }
}

impl QueryFeltDrop of Drop::<Query::<felt>>;
impl DictFeltToDrop of Drop::<DictFeltTo::<felt>>;

#[test]
fn test_query() {
    let mut query = QueryTrait::<felt>::new();
    query.destroy();
}

Fails with:

error: Variable not dropped.
 --> query.cairo:20:9
        data.squash();
        ^***********^

dev: broken internal links to cairo-lang-runner and cairo-lang-test-runner

In the global readme, in the Getting Started --> Compiling and running Cairo files section, link to :

./crates/cairo-runner/README.md
./crates/cairo-test-runner/README.md

does not work. They have to be changed to :

./crates/cairo-lang-runner/README.md
./crates/cairo-lang-test-runner/README.md

bug:

Bug Report

Cairo version:
PR - #1657
commit - 0cc4760

Current behavior:
I am able to re-assign a mutable Uin256 value with a felt. This reassigned variable is unable to be returned or used in an operation without the runner running into a type issue

Expected behavior:
I could see a couple possible behaviors.

The runner fails at the improper felt assignment.
There is a type issue that needs a better error message from the compiler (point to where in the code the type error is and what the conflicting types are)
We are able to return the variable and do different operations with it.

Steps to reproduce:
Create a temp.cairo with the related code
cargo run --bin cairo-run -- -p ./temp.cairo

Related code:
This code is able to run

fn main() {  

    let mut x : u256 = u256_from_felt(10000);

    x = 100;
    
}

This code is not able to run

fn main() -> u256 implicits(RangeCheck) {  

    let mut x : u256 = u256_from_felt(10000);

    x = 100;

    return x;

}

Other information:
When changing the expected return value we get a helpful message from the compiler

error: Unexpected return type. Expected: "core::felt", found: "core::integer::u256".
 --> temp.cairo:7:12
    return x;

I'd like to see something similar for the not working code above. For now we recieve

Error: Failed setting up runner.

Caused by:
    One of the arguments does not match the expected type of the libfunc or return statement.

Feel free to point out the related code and I can make the fix.

bug: Trait `core::serde::Serde::<core::starknet::ContractAddress>` has no implementation in the context.

Bug Report

Cairo version:

b51c511ab39dae631362d4157853db46c2c49d64

Current behavior:

Calling a method on a starknet contract trait that accepts a ContractAddress as input results in the following:

#[abi]
trait IProxy {
    fn initialize(world_address: starknet::ContractAddress);
}

error: Trait `core::serde::Serde::<core::starknet::ContractAddress>` has no implementation in the context.
 --> IProxyDispatcher:19:9
        serde::Serde::<starknet::ContractAddress>::serialize(ref calldata, world_address);
        ^*******************************************************************************^

Error: failed to compile: lib

full repo here: dojoengine/dojo#51

bug: Libfunc alloc_local is not allowed in the libfuncs list 'audited_v0.1.0'

Bug Report

Cairo version: commit 382ff3f

Current behavior:
Unable to build https://github.com/Th0rgal/erc721/tree/50098af2b39da7ca31bf6b887d6ccb5e8eeea783

client-172-18-90-109:erc721 thomas$ make starknet-compile dir=src/erc721
    Finished dev [unoptimized + debuginfo] target(s) in 0.47s
     Running `target/debug/starknet-compile src/erc721 out/erc721.json`
Error: Libfunc alloc_local is not allowed in the libfuncs list 'audited_v0.1.0'.
 Run with '--allowed_libfuncs_list_name experimental_v0.1.0' to allow all libfuncs.
make: *** [starknet-compile] Error 1

Expected behavior:
This should build

Steps to reproduce:

git clone https://github.com/Th0rgal/erc721
git checkout 50098af2b39da7ca31bf6b887d6ccb5e8eeea783
make starknet-compile dir=src/erc721

Other information:
I'm not sure if this is a bug or I just did something wrong.

bug: Argument to immutable parameter cannot have modifiers. for `mut` array input

The following code:

    fn entities_inner(component_address: starknet::ContractAddress, entities_len: usize, mut entities: Array::<usize>) {
        if (entities_len == 0_usize) {
            return ();
        }

        let entity_id = entity_registry::read((component_address, (entities_len - 1_usize)));
        entities.append(entity_id);

        entities_inner(component_address, entities_len - 1_usize, mut entities);
    }

    #[view]
    fn entities(component_address: starknet::ContractAddress) -> Array::<usize> {
        let entities_len = entity_registry_len::read(component_address);
        let mut entities = ArrayTrait::new();
        entities_inner(component_address, entities_len, mut entities);
        return entities;
    }

Results in the error:

error: Plugin diagnostic: Unknown function.
 --> world.cairo:80:18
        entities.append(entity_id);
                 ^****^

error: Plugin diagnostic: Argument to immutable parameter cannot have modifiers.
 --> world.cairo:82:71
        entities_inner(component_address, entities_len - 1_usize, mut entities);
                                                                      ^******^

error: Plugin diagnostic: Argument to immutable parameter cannot have modifiers.
 --> world.cairo:89:61
        entities_inner(component_address, entities_len, mut entities);

As far as I can tell, this should work since we're passing a mutable array to the inner method and have the mut modifier. Is there something I am doing incorrectly?

dev: `get_caller_address` should return `ContractAddress`

The get_caller_address should return a ContractAddress to avoid having to use contract_address_try_from_felt which seems unnecessary?

A to_felt method for ContractAddress would also be great.

feat: Structure referencing itself

Feature Request

Describe the Feature Request

It should be possible for a structure to reference itself:

struct Node {
    value: felt,
    left: Option::<Box::<Node>>,
    right: Option::<Box::<Node>>,
}

If the feature request is approved, would you be willing to submit a PR?
(Help can be provided if you need assistance submitting a PR)

I'd have no idea how to implement that feature.

dev: make binary target names cairo/starknet specific

There are currently 8 binary targets in this repo:

sierra-compile
generate_syntax
languageserver
cairo-run
formatter_cli
starknet-compile
starknet-sierra-compile
cairo-compile

Out of which these 2 are not cairo/starknet specific (excluding generate_syntax since it looks like an internal tool only):

languageserver
formatter_cli

This can cause issues like name clashes when installed, and users will have to invoke the fomatter like:

$ formatter_cli

instead of something like cairo-fmt. I suggest we change them to:

cairo-lsp
cairo-fmt

respectively.

Ideally we should also change package names, not just for binary targets, but that would introduce a large amount of diffs that would likely interfere with other ongoing development efforts.

What do you think?

Update on 2022-11-26:

Here are the suggested new names:

Current Name	Available	Suggested New Name
`casm`	❌	`cairo-asm`
`compiler`	✅	`cairo-compiler`
`db_utils`	✅	`cairo-db-utils`
`debug`	✅	`cairo-debug`
`defs`	❌	`cairo-defs`
`diagnostics`	❌	`cairo-dxs`
`diagnostics_proc_macros`	✅	`cairo-dxs-macros`
`filesystem`	❌	`cairo-fs`
`formatter`	✅	`cairo-fmt`
`languageserver`	✅	`cairo-lsp`
`lowering`	✅	`cairo-lowering`
`parser`	❌	`cairo-parser`
`project`	❌	`cairo-project`
`runner`	❌	`cairo-runner`
`semantic`	❌	`cairo-semantic`
`sierra`	❌	`sierra-ir`
`sierra_gas`	✅	`sierra-gas`
`sierra_generator`	✅	`sierra-generator`
`sierra_to_casm`	✅	`sierra-compile`
`starknet`	❌	`cairo-starknet`
`syntax`	✅	`cairo-syntax`
`utils`	❌	`cairo-utils`

dev: tree-sitter formal syntax definition?

The old cairo-lang repo comes with an EBNF definition of the Cairo syntax, which makes it easy to build and maintain the treesitter grammar, along with other benefits.

Maybe I missed it, but it looks like the new repo doesn't provide such a definition. Would be nice it exists. I'm trying to build the Cairo 1.0 treesitter grammar so that syntax hightlighting, folding, etc. work in editors that support it (Helix, nvim, etc.).

bug: returning array from `#[view]` function results in move error

The following contract:

#[contract]
mod Test {
    use array::ArrayTrait;

    fn get_inner(len: usize, mut entities: Array::<felt>) {
        if (len == 0_usize) {
            return ();
        }
        return get_inner(len - 1_usize, entities);
    }

    #[view]
    fn get() -> Array::<felt> {
        let mut values = array_new();
        get_inner(1_usize, values);
        return values;
    }
}

Results in the follow compilation error:

error: Variable was previously moved.
 --> contract:16:13
        let mut values = array_new();
            ^********^

bug: cargo install `cairo-lang-test-runner` does not compile

Bug Report

Cairo version: tried all

Current behavior:

Not having any trouble install/compiling Rust packages in general, but none of the following commands work:

cargo install cairo-lang-test-runner
cargo install [email protected]
cargo +nightly install cairo-lang-test-runner

FYI - the installation process until failure is also very slow (~2-5 min.).

Here is an example of an error (but there are many more):

note: associated function defined here
   --> /Users/~/.cargo/registry/src/github.com-1ecc6299db9ec823/cairo-vm-0.1.3/src/vm/vm_core.rs:105:12
    |
105 |     pub fn new(trace_enabled: bool) -> VirtualMachine {
    |            ^^^
help: remove the extra arguments
    |
293 |     let mut vm = VirtualMachine::new(true);

...

error: could not compile `cairo-lang-casm` due to 34 previous errors
warning: build failed, waiting for other jobs to finish...
error: failed to compile `cairo-lang-test-runner v0.1.0`, intermediate artifacts can be found at `/var/folders/2r/klcq017520n9y17fq1wklky80000gn/T/cargo-installdQu0Tf`

Suggests that different versions are being compiled at once.

Expected behavior:

It should successfully install.

Steps to reproduce:

cargo install cairo-lang-test-runner

bug: IContractDispatcher ContractAddress serde

Bug Report

Cairo version:
1.0.0-alpha.3

Current behavior:
IContractDispatcher tries to access from serde::ContractAddressSerde but it's implemented in starknet::contract_address::ContractADdressSerde

However, implementing serde::Serde::ContractAddressSerde to use in IContractDispatcher causes a conflict with the existing definition in starknet::contract_address::ContractAddressSerde used in the generated contract.cairo

Expected behavior:
ContractAddress serde is accessible from both IContractDispatcher and the generated contract.cairo without clashes.

This can be fixed by adding the line

use starknet::contract_address::ContractAddressSerde

in serde.cairo
in the

Steps to reproduce:

Related code:

#[abi]
trait IContract {
    fn serde_conflict -> ContractAddress;

Other information:

Naming Conflict

Bug Report

The name Cairo is already being used by Cairo, a very popular and commonly used 2D graphics library. It even has it's own Wikipedia page!

The Cairo graphics library is used by GTK and FLTK, two very popular GUI toolkits.

bug: Error: Libfunc alloc_local is not allowed in the libfuncs list 'audited_v0.1.0'.

Bug Report

Cairo version:

c6473b4

Related code:

#[contract]
mod ERC20 {
    struct Storage {
        name: felt,
        symbol: felt,
        decimals: u8,
        total_supply: u256,
        balances: LegacyMap::<felt, u256>,
        allowances: LegacyMap::<(felt, felt), u256>,
    }

    // TODO(ilya): use `ContractAddress` for addresses in this contract and remove the following.
    // A wrapper around get_caller_address that returns a felt.
    fn get_caller_address() -> felt {
        starknet::contract_address_to_felt(starknet::get_caller_address())
    }

    #[event]
    fn Transfer(from: felt, to: felt, value: u256) {}

    #[event]
    fn Approval(owner: felt, spender: felt, value: u256) {}

    #[constructor]
    fn constructor(
        name_: felt, symbol_: felt, decimals_: u8, initial_supply: u256, recipient: felt
    ) {
        name::write(name_);
        symbol::write(symbol_);
        decimals::write(decimals_);
        assert(recipient != 0, 'ERC20: mint to the 0 address');
        total_supply::write(initial_supply);
        balances::write(recipient, initial_supply);
        Transfer(0, recipient, initial_supply);
    }

    #[view]
    fn get_name() -> felt {
        name::read()
    }

    #[view]
    fn get_symbol() -> felt {
        symbol::read()
    }

    #[view]
    fn get_decimals() -> u8 {
        decimals::read()
    }

    #[view]
    fn get_total_supply() -> u256 {
        total_supply::read()
    }

    #[view]
    fn balance_of(account: felt) -> u256 {
        balances::read(account)
    }

    #[view]
    fn allowance(owner: felt, spender: felt) -> u256 {
        allowances::read((owner, spender))
    }

    #[external]
    fn transfer(recipient: felt, amount: u256) {
        let sender = get_caller_address();
        transfer_helper(sender, recipient, amount);
    }

    #[external]
    fn transfer_from(sender: felt, recipient: felt, amount: u256) {
        let caller = get_caller_address();
        spend_allowance(sender, caller, amount);
        transfer_helper(sender, recipient, amount);
    }

    #[external]
    fn approve(spender: felt, amount: u256) {
        let caller = get_caller_address();
        approve_helper(caller, spender, amount);
    }

    #[external]
    fn increase_allowance(spender: felt, added_value: u256) {
        let caller = get_caller_address();
        approve_helper(caller, spender, allowances::read((caller, spender)) + added_value);
    }

    #[external]
    fn decrease_allowance(spender: felt, subtracted_value: u256) {
        let caller = get_caller_address();
        approve_helper(caller, spender, allowances::read((caller, spender)) - subtracted_value);
    }

    fn transfer_helper(sender: felt, recipient: felt, amount: u256) {
        assert(sender != 0, 'ERC20: transfer from 0');
        assert(recipient != 0, 'ERC20: transfer to 0');
        balances::write(sender, balances::read(sender) - amount);
        balances::write(recipient, balances::read(recipient) + amount);
        Transfer(sender, recipient, amount);
    }

    fn spend_allowance(owner: felt, spender: felt, amount: u256) {
        let current_allowance = allowances::read((owner, spender));
        let ONES_MASK = 0xffffffffffffffffffffffffffffffff_u128;
        let is_unlimited_allowance =
            current_allowance.low == ONES_MASK & current_allowance.high == ONES_MASK;
        if !is_unlimited_allowance {
            approve_helper(owner, spender, current_allowance - amount);
        }
    }

    fn approve_helper(owner: felt, spender: felt, amount: u256) {
        assert(spender != 0, 'ERC20: approve from 0');
        allowances::write((owner, spender), amount);
        Approval(owner, spender, amount);
    }
}

Result

cargo run --bin starknet-compile contracts/erc20.cairo outputs/erc20.json                                                                                          
    Finished dev [unoptimized + debuginfo] target(s) in 0.21s
     Running `target/debug/starknet-compile contracts/erc20.cairo outputs/erc20.json`
Error: Libfunc alloc_local is not allowed in the libfuncs list 'audited_v0.1.0'.

Other information:

bug: Variable has previously moved - even with #[derive(Copy)]

Bug Report

Cairo version:

0.1.0 (workspace.package version)

Current behavior:

#[derive(Copy, Drop)] doesn't fix "Variable has previously moved." error.

Expected behavior:

#[derive(Copy, Drop)] allows reusing thte variable.

Steps to reproduce:

Run the examples/fib_struct.cairo

cargo run --bin cairo-run -- --path examples/fib_struct.cairo

Related code:

// Calculates fib...
#[derive(Copy, Drop)]
struct FibResult { value: felt, index: felt, nothing: () }

func fib(a: felt, b: felt, n: felt) -> FibResult {
    match n {
        0 => FibResult { nothing: (), value: a, index: 0 },
        _ => {
            let r = fib(b, a + b, n - 1);
            FibResult { value: r.value, nothing: (), index: r.index + 1 }
        },
    }
}

func main() -> FibResult {
    fib(1, 1, 7)
}

Throws this error

error: Variable has previously moved.
 --> fib_array.cairo:10:61
            FibResult { value: r.value, nothing: (), index: r.index + 1 }

bug: cairo_filesystem detect_corelib fails when used as a git dependency

Bug Report

Cairo version:

74b4d12

Current behavior:

thread 'main' panicked at 'Corelib not found.', /Users/shramee/.cargo/git/checkouts/cairo-f086c7e6d4098a68/74b4d12/crates/cairo-filesystem/src/detect.rs:34:5

When using cairo_compiler::db::RootDatabase; to get default let mut db_val = RootDatabase::default();

Using crates from the git repo like so,

# . . .
[dependencies]

# Members of starkware-libs/cairo
# . . .
cairo-filesystem = { git = "https://github.com/starkware-libs/cairo" }
cairo-compiler = { git = "https://github.com/starkware-libs/cairo" }
# . . .

Expected behavior:

Corelib dir to be found from installed git crate path.

Steps to reproduce:

Related code:

Tiniest reproducible version:

Issue is in cairo_filesystem::detect::detect_corelib.

Cargo.toml

[package]
name = "cairo-corelibs-bug"
version = "0.1.0"
edition = "2021"

[dependencies]
cairo-filesystem = { git = "https://github.com/starkware-libs/cairo" }

[[bin]]
name = "test"
path = "test.rs"

test.rs

use cairo_filesystem::detect::detect_corelib;
fn main() {
    let path = detect_corelib();
    print!("Found corelibs at {:#?}.", path);
}

Other information:

bug: Failed setting up runner when array.len() and array.is_empty() are used

Bug Report

Cairo version:
Commit 1991669

Current behavior:

Error: Failed setting up runner.

Caused by:
    #27: [1] is undefined.

Expected behavior:
The program runs without errors.

Steps to reproduce:
Execute cairo-run on the following Cairo program

Related code:

use array::ArrayTrait;
fn main() {
    let mut a = ArrayTrait::<felt>::new();
    assert(a.len() == 0_usize, 'Array length is not 0');
    assert(a.is_empty() == true, 'Array is not empty');
}

Other information:

bug: Can't execute release binaries

Bug Report

Release binaries are only available on Linux?

Cairo version:

1.0.0-alpha.3

Current behavior:

From macOS x86, when trying to run the binaries from the release, I get this error:

zsh: exec format error:

I have also tried with bash and got a similar error.

Expected behavior:

Can run binaries from my OS as well as my friend Jane's OS.

Steps to reproduce:

Download release from GitHub
Attempt to execute a binary. It fails saying it is wrong format or something.

Related code:

./starknet-compile

Other information:

bug: Help Info Inaccurate

Bug Report

Cairo version:

version_check v0.9.4

Current behavior:

Options:
  -p, --path <PATH>                    The file to compile and run
      --available-gas <AVAILABLE_GAS>  In cases where gas is available, the amount of provided gas
      --print-full-memory              In cases where gas is available, the amount of provided gas-h, 
      --help                           Print help information
  -V, --version                        Print version information

Expected behavior:

Options:
  -p, --path <PATH>                    The file to compile and run
      --available-gas <AVAILABLE_GAS>  In cases where gas is available, the amount of provided gas
      --print-full-memory              print memory
  -h, --help                           Print help information
  -V, --version                        Print version information

Steps to reproduce:

$cargo run --bin cairo-run -h

Related code:

$cargo run --bin cairo-run -h

Other information:

bug: formatting of struct is incorrect

Bug Report

Cairo version:

Commit: 775dded

Current behavior:

Formatting of struct is incorrect.
Expected behavior:

Formatting of struct is correct/

Steps to reproduce:

Current behavior:

Expected:

bug: Wrong Drops

The following code tried to Drop Pedersen.

fn reproduce_bug() {
    match get_gas_all(get_builtin_costs()) {
        Option::Some(_) => {},
        Option::None(_) => {
            let mut data = ArrayTrait::new();
            data.append('OOG');
            panic(data);
        }
    }
    let a = 1;
    let b = 2;
    let mut c = 0;
    if a < b {
        c = LegacyHash::hash(a, b);
    } else {
        c = LegacyHash::hash(b, a);
    }
}

bug: `é` and likely other characters in comments make compilation fail and VS code extension crash

Bug Report

Cairo version: 3b92682

Current behavior:

When including a é in a comment, the VS code extension crashed and the compilations fails as well.

Error is:

thread 'main' panicked at 'byte index 176 is not a char boundary; it is inside 'é' (bytes 175..177) of `/// ....

Expected behavior:

I expect é to be supported in comment.

Steps to reproduce:

Add a é in a comment
Save file (VS code will crash)
Compile with command line (compilation will fail)

Sierra ids

In the sierra crate, Id(Identity) is 64-bit, and is sometimes generated from string hashes (mostly for testing), which may cause collisions.
Suggested solution:
Separate between GenericIds (global 256-bit hashes for extension names and parameters) and ConcreteIds (64-bit running numbers, bounded in the context of a specific program)

	assert!(
	self.state_opt.is_none(),
	"Internal compiler error: Found a reachable statement at the end of the function."
	);

	if !diagnostics.0.leaves.is_empty() {
	eprintln!(
	"{}",
	format!("A parsing error occurred in file: {file_path}. The file was not formatted.")
	.red()
	);
	return true;
	}

	Ok(Some(vec![TextEdit {
	range: Range {
	start: Position { line: 0, character: 0 },
	end: Position { line: u32::MAX, character: 0 },
	},
	new_text,
	}]))

starkware-libs / cairo Goto Github PK

cairo's People

Contributors

Stargazers

Watchers

Forkers

cairo's Issues

Bug Report

Feature Request

Feature Request

Bug Report

Bug Report

Bug Report

Bug Report

Feature Request

Bug Report

Bug Report

Bug Report

Feature Request

Bug Report

Description Inaccurate Report

Bug Report

Feature Request

Bug Report

Bug Report

Bug Report

Bug Report

Other information:

Bug Report

Bug Report

Bug Report

Bug Report

Feature Request

Bug Report

Bug Report

Bug Report

Bug Report

Bug Report

Bug Report

Cargo.toml

test.rs

Bug Report

Bug Report

Bug Report

Bug Report

Bug Report

Recommend Projects

Recommend Topics

Recommend Org