[cartesian] out of bound reads on vertical axis not reported

[romanc]

Description

One of the main selling points of gt4py is that it reports out of bound reads through static analysis of the bounds and index accesses. Below is a case where this analysis fails and out of bound reads happen. We should catch this and throw an error instead. The provided stencil can be used as the basis for a test case.

Repro

in_field and out_field are 3-dimensional arrays.

@gtscript.stencil()
def test_stencil(out_field: FloatField, in_field: FloatField):
   # temporary with only one vertical dimension
    with computation(FORWARD), interval(-1, None):
        temp = 2

    # offset read in the vertical dimension
    with computation(FORWARD), interval(-1, None):
        out_field = temp[0,0,-1]  # <- this reads out of bounds and is not reported

[romanc]

Bonus points if we manage to emit a warning in the following case where the interval(5, None) restricts the computation to outside the domain (only 2 in the vertical axis) and thus nothing happens. This is valid code. Would just be nice to emit a warning.

from gt4py.cartesian.gtscript import PARALLEL, computation, interval, stencil
from ndsl.dsl.typing import FloatField
from ndsl.quantity import Quantity
import numpy as np

backend = "dace:cpu"

nx = 3
ny = 4
nz = 2 # <- vertical domain size is 2 only

shape = (nx, ny, nz)

qty_out = Quantity(
    data=np.zeros([nx, ny, nz]), dims=["I", "J", "K"], units="m", gt4py_backend=backend
)

arr = np.indices(shape, dtype=float).sum(
    axis=0
)  # Value of each entry is sum of the I and J index at each point

qty_in = Quantity(data=arr, dims=["I", "J", "K"], units="m", gt4py_backend=backend)


@stencil(backend=backend, rebuild=True)
def copy_stencil(input_field: FloatField, output_field: FloatField):
    with computation(PARALLEL), interval(5, None): # <- interval starts outside the domain
        output_field = input_field


copy_stencil(qty_in, qty_out)

[romanc]

We figured that in dace orchestration, the current out-of-bounds read/write analysis comes too late in the pipeline, leaving people with (cryptic) SDFG validation errors instead of (clean) extent analysis error messages. That only happens in orchestration because only in orchestration we freeze origin/domain with the stencil. In GridTools workflow, origin and domain are a call arguments and thus we can only check this at call time. And apparently we always check this at call time, even in orchestration workflow. This leads orchestration workflows to fail (at build time) even before we get to the analysis (at call time).