Srcinfo and error reporting about exo HOT 5 OPEN

What I am generally saying is that if the user asks Exo to do some action A (scheduling, codegen, other?) on some procedure P, then error reporting should be with respect to procedure P which is not always the case right now. The extension of this is what you described: I ask an abstraction to do something on a program P and error reporting should be on P.

from exo.

Thanks for writing this up! In general, this is a tricky problem that all compiler (not just rewrite-based ones) have to deal with. Even in a standard compiler, the intermediate representation is derived from normalization of surface constructs which requires the same kind of tracking. There are different trade-offs you can make w.r.t. to the amount of information tracked and the precision of the error messages.

For example, the Rust compiler uses the Diagnostics struct for reporting error messages. The error messages, especially when generated from a type error, often represent a tree of rewrites from source-level AST to the internal representation which allows Rust to provide error messages that meaningful for a particular context.

As a maximalist, strawperson proposal, maybe the thing to do is tracking all of the source information generated when rewriting programs. For example, when a loop is fused, we add a srcinfo node that literally says that this node is derived from these other two loops.

from exo.

I think the difference here is that I the user was the person who drove the rewrites to this point vs in rust the compiler did so. In Exo, I don't particularly care about the original procedure. I care about where I am at now and where the problem is here.

from exo.

Hm, but that assumes that you, as the user, have seen each rewrite. This is not going to be true when using the abstracted scheduling operators. For example, if there is an error in the middle of vectorize, which version of the program should the error be reported on. Ideally we'd want the diagnostics mechanism to have a hook that says "start tracking all the rewrites from now on" and report the transformations that occurred within vectorize, showing the trace of rewritten programs which might give an insight into what caused the error.

A similar problem might arise when building Halide-like automation which parameterizes the lowering process and triggers bound inference on some IR which is not meaningful to someone working with a surface program.

from exo.

Now we are discussing a different problem. What you are describing is the next problem to solve if we implement what I described above. The confusion I think is that srcinfo in Exo is information about line and column numbers in the Python source file from which the current AST node originated.

from exo.