Add IntoBox instead of into_box in lowering

[giladchase]

Currently is always mapped to into_box during sierra-gen, but soon in sierra-gen it can also be
mapped into local_into_box when applicable.

[reviewable-StarkWare]

This change is 

[giladchase]

• Add IntoBox instead of into_box in lowering #8967 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[orizi]

@orizi reviewed 1 of 14 files at r1.
Reviewable status: 0 of 14 files reviewed, 1 unresolved discussion (waiting on @eytan-starkware and @giladchase)

---

crates/cairo-lang-lowering/src/lower/mod.rs line 1396 at r1 (raw file):

    // Handle into_box specially - emit IntoBox instead of a call.
    let into_box_fn = ModuleHelper::core(ctx.db).submodule("box").extern_function_id("into_box");

add to CoreInfo instead of calling every time.

[giladchase]

Reviewable status: 0 of 15 files reviewed, 1 unresolved discussion (waiting on @eytan-starkware and @orizi)

---

crates/cairo-lang-lowering/src/lower/mod.rs line 1396 at r1 (raw file):

Previously, orizi wrote…

add to CoreInfo instead of calling every time.

Done.
I'm assuming Is it OK to add ExternFunctionId there, rather than just adding box submodule and call extern_function_id (context: this is the first time ExternFunctionIds are added to CoreInfo)

[orizi]

@orizi reviewed 9 of 14 files at r1, 1 of 1 files at r2, 1 of 2 files at r3, all commit messages.
Reviewable status: 11 of 15 files reviewed, 1 unresolved discussion (waiting on @eytan-starkware and @giladchase)

---

crates/cairo-lang-semantic/src/corelib.rs line 1147 at r3 (raw file):

            upcast_fn: bounded_int.generic_function_id("upcast"),
            downcast_fn: bounded_int.generic_function_id("downcast"),
            into_box: core.submodule("box").extern_function_id("into_box"),

Suggestion:

            into_box: box_module.extern_function_id("into_box"),

[orizi]

@orizi reviewed 3 of 14 files at r1.
Reviewable status: 14 of 15 files reviewed, 1 unresolved discussion (waiting on @eytan-starkware and @giladchase)

[giladchase]

Reviewable status: 14 of 15 files reviewed, 1 unresolved discussion (waiting on @eytan-starkware and @orizi)

---

crates/cairo-lang-semantic/src/corelib.rs line 1147 at r3 (raw file):

            upcast_fn: bounded_int.generic_function_id("upcast"),
            downcast_fn: bounded_int.generic_function_id("downcast"),
            into_box: core.submodule("box").extern_function_id("into_box"),

Done.

[giladchase]

Reviewable status: 14 of 15 files reviewed, 2 unresolved discussions (waiting on @eytan-starkware and @orizi)

---

-- commits line 1 at r4:
Blocking merge: until we finish the stack.

[orizi]

@orizi reviewed 1 of 1 files at r4, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @eytan-starkware and @giladchase)

[eytan-starkware]

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @giladchase and @orizi)

---

-- commits line 1 at r4:

Previously, giladchase wrote…

Blocking merge: until we finish the stack.

I am not sure what the full stack holds, but I think if we have IntoBox we should also have Unbox treated the same. We also have different analysis not sure if you dealt with all of them. I saw const folding, what about the statement reordering?

[orizi]

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @giladchase)

---

-- commits line 1 at r4:

Previously, eytan-starkware wrote…

I am not sure what the full stack holds, but I think if we have IntoBox we should also have Unbox treated the same. We also have different analysis not sure if you dealt with all of them. I saw const folding, what about the statement reordering?

Yeah, unboxing as well makes sense to me.
Regarding the other algorithm, I think all non-function calls are movable anyway, but we need to validate.