Thanks for following up! > the parser and IRBuilder are only called for statements and for function > calls. Is this correct?
In fact we allow registering visitors for any Python AST constructs. For example, we could specify the behavior when visiting type annotations, function arguments, etc. > And I want this buffer to be a `TIRBuffer` when the language is tir and a > `RelaxBuffer` when the language is relax. It’s allowed with our infrastructure, but in reality, we instead prefer to use prefix, i.e. `T.Buffer` and `R.Buffer` which is more friendly to python tooling. > how does this IRBuilder approach handle error catching and reporting It handles error reporting in a consistent approach with the current parser, i.e. using `DiagnosticContext` and its rendering. In your specific case, where the error comes from a type mismatch of a particular parameter of a function call, despite being not well supported in the current parser (only supported in a small subset of buffer-related intrinsics: [`match_buffer`](https://github.com/apache/tvm/blob/df29e826290a3eba606a93b59f640e025b5cbd4d/python/tvm/script/tir/special_stmt.py#L144-L147), [`buffer_decl`](https://github.com/apache/tvm/blob/df29e826290a3eba606a93b59f640e025b5cbd4d/python/tvm/script/tir/special_stmt.py#L217-L220), [`alloc_buffer`](https://github.com/apache/tvm/blob/df29e826290a3eba606a93b59f640e025b5cbd4d/python/tvm/script/tir/special_stmt.py#L277-L279)) and the mechanism is not general enough, it is in fact one of our design consideration before starting to work on this project, as well as overall tooling of the entire TVM project. A general mechanism is that we interpret expressions in finer-grained level and do runtime type checking. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/79#issuecomment-1204646078 You are receiving this because you are subscribed to this thread. Message ID: <apache/tvm-rfcs/pull/79/c1204646...@github.com>
