High level support and testsing for span-to-fixed-sized array.

[orizi]

Stack:

• Using multi-pop in sha256 impl. #5590
• Added high level support and tests for multi pops. #5589
• Added multi-pop for span. #5588
• Changed sha256 compress signature. #5584
• High level support and testsing for span-to-fixed-sized array. #5583 ⬅

⚠️ Part of a stack created by spr. Do not merge manually using the UI - doing so may have unexpected results.

---

This change is 

[TomerStarkware]

Reviewable status: 0 of 3 files reviewed, all discussions resolved (waiting on @ilyalesokhin-starkware)

[ilyalesokhin-starkware]

corelib/src/array.cairo line 274 at r1 (raw file):

}

impl SpanTryIntoEmptyFixedSizedArray<T, +Drop<T>> of TryInto<Span<T>, Box<@[T; 0]>> {

why is this needed?

Code quote:

SpanTryIntoEmptyFixedSizedArray<T, +Drop<T>> of TryInto<Span<T>, Box<@[T; 0]>>

[orizi]

Reviewable status: 0 of 3 files reviewed, 1 unresolved discussion (waiting on @ilyalesokhin-starkware)

---

corelib/src/array.cairo line 274 at r1 (raw file):

Previously, ilyalesokhin-starkware wrote…

why is this needed?

this just makes try-into for empty sized arrays work.

[ilyalesokhin-starkware]

corelib/src/array.cairo line 262 at r1 (raw file):

/// The additional `+Copy<@T>` arg is to prevent later stages from propagating the `S` type Sierra
/// level, where it is deduced by the `T` type.
extern fn tuple_from_span<T, +Copy<@T>, S>(span: @Array<S>) -> Option<Box<@T>> nopanic;

why can't we use the following signature?

Suggestion:

extern fn tuple_from_span<T, SIZE: u32>(span: @Array<T>) -> Option<Box<[T, SIZE]>> nopanic;

[orizi]

Reviewable status: 0 of 3 files reviewed, 2 unresolved discussions (waiting on @ilyalesokhin-starkware)

---

corelib/src/array.cairo line 262 at r1 (raw file):

Previously, ilyalesokhin-starkware wrote…

why can't we use the following signature?

no - look at the above comment.
will change it to be inner type based soon.

but currently like span_from_tuple

[ilyalesokhin-starkware]

corelib/src/array.cairo line 262 at r1 (raw file):

Previously, orizi wrote…

no - look at the above comment.
will change it to be inner type based soon.

but currently like span_from_tuple

I read the comment and didn't understand it.

[orizi]

Reviewable status: 0 of 3 files reviewed, 2 unresolved discussions (waiting on @ilyalesokhin-starkware)

---

corelib/src/array.cairo line 262 at r1 (raw file):

Previously, ilyalesokhin-starkware wrote…

I read the comment and didn't understand it.

the only type in the generics of the libfunc is T - the following args must not be passed to the libfunc.
since i want it to be exactly the same as span_from_tuple i don't want to limit it to only returning the fixed_size_array in the libfunc - so we are only dependent on the tuple like struct T, and the size is not part of the signature.

[ilyalesokhin-starkware]

corelib/src/array.cairo line 262 at r1 (raw file):

Previously, orizi wrote…

the only type in the generics of the libfunc is T - the following args must not be passed to the libfunc.
since i want it to be exactly the same as span_from_tuple i don't want to limit it to only returning the fixed_size_array in the libfunc - so we are only dependent on the tuple like struct T, and the size is not part of the signature.

"the following args must not be passed to the libfunc."
what does that mean?

[orizi]

Reviewable status: 0 of 3 files reviewed, 2 unresolved discussions (waiting on @ilyalesokhin-starkware)

---

corelib/src/array.cairo line 262 at r1 (raw file):

Previously, ilyalesokhin-starkware wrote…

"the following args must not be passed to the libfunc."
what does that mean?

it isn't part of the expected generic args by sierra.

[ilyalesokhin-starkware]

corelib/src/array.cairo line 262 at r1 (raw file):

Previously, orizi wrote…

it isn't part of the expected generic args by sierra.

how does +Copy<@t> prevent propagating the S type to sierra

[orizi]

Reviewable status: 0 of 3 files reviewed, 2 unresolved discussions (waiting on @ilyalesokhin-starkware and @t)

---

corelib/src/array.cairo line 262 at r1 (raw file):

Previously, ilyalesokhin-starkware wrote…

how does +Copy<@t> prevent propagating the S type to sierra

impl args and everything following are not passed to sierra.

[ilyalesokhin-starkware]

corelib/src/array.cairo line 262 at r1 (raw file):

Previously, orizi wrote…

impl args and everything following are not passed to sierra.

Why did you decide on using +Copy
instead of +IgnoreFollowingArgs?

[ilyalesokhin-starkware]

corelib/src/array.cairo line 262 at r1 (raw file):

Previously, ilyalesokhin-starkware wrote…

Why did you decide on using +Copy
instead of +IgnoreFollowingArgs?

maybe use
S_
?

[orizi]

Reviewable status: 0 of 3 files reviewed, 2 unresolved discussions (waiting on @ilyalesokhin-starkware and @t)

---

corelib/src/array.cairo line 262 at r1 (raw file):

Previously, ilyalesokhin-starkware wrote…

maybe use
S_
?

it is already used - and will soon be removed - rather not add boilerplate for this PR.

[ilyalesokhin-starkware]

corelib/src/test/array_test.cairo line 149 at r3 (raw file):

}

fn debox<T, const SIZE: usize>(value: Option<@Box<[T; SIZE]>>) -> Option<@[T; SIZE]> {

what is debox?
can you document it?

Code quote:

debox

[orizi]

Reviewable status: 0 of 3 files reviewed, 3 unresolved discussions (waiting on @ilyalesokhin-starkware and @t)

---

corelib/src/test/array_test.cairo line 149 at r3 (raw file):

Previously, ilyalesokhin-starkware wrote…

what is debox?
can you document it?

Done.

[ilyalesokhin-starkware]

corelib/src/test/array_test.cairo line 149 at r3 (raw file):

Previously, orizi wrote…

Done.

Why do you need to wrap it in a snapshot?

[orizi]

Reviewable status: 0 of 3 files reviewed, 3 unresolved discussions (waiting on @ilyalesokhin-starkware and @t)

---

corelib/src/test/array_test.cairo line 149 at r3 (raw file):

Previously, ilyalesokhin-starkware wrote…

Why do you need to wrap it in a snapshot?

The input already had a snapshot, leaving the snapshot here remove the need to require the data to have Copy

[ilyalesokhin-starkware]

Reviewed 2 of 3 files at r1, 1 of 2 files at r2, 1 of 1 files at r4, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @orizi)