chore: making it easier to debug making array

[rluvaton]

Rationale for this change

Debugging ArrayRef is a nightmare:

for this example code:

let my_array = make_array(...)

the lldb is:

(lldb) frame variable my_array
(alloc::sync::Arc<dyn arrow_array::array::Array, alloc::alloc::Global>) values = strong=1, weak=0 {
  data = {}
}

now, we can put a debugger before casting to ArrayRef making our life a little easier

[tustvold]

Why can't you just put a breakpoint on make_array? If you really need to be in the match block you can step in the debugger?

[rluvaton]

Why can't you just put a breakpoint on make_array? If you really need to be in the match block you can step in the debugger?

yes, but I want to view the value that created inside the make array before casting:

If something create an array with Int32Type I debug the created array value before casting, but I can't as it's immediately passed to arc and casted

        DataType::Int32 => Arc::new(Int32Array::from(data)) as ArrayRef,

I want to debug this value Int32Array::from(data) for example

[tustvold]

but I can't as it's immediately passed to arc and casted

Most debuggers call this step into, if you put a breakpoint on the line, you will then be able to "step-into" the nested context.

[rluvaton]

step into will go inside the function I want the result of that function

[tustvold]

step into will go inside the function I want the result of that function

Step into and then step out, and it will show you this.

TBC we simply cannot be in a position where everything must be declared as a separate named variable just for debugging, that is not a precedent that makes sense

[rluvaton]

step into will go inside the function I want the result of that function

Step into and then step out, and it will show you this.

Already tried before doing this pr...

[tustvold]

Then step into the Arc::new call? I'm sorry but we simply can't be altering code in this way