HaxeFoundation / HaxeFoundation/haxe
Fatal errors reported incorrectly during macro execution
- Dominant language
- Haxe
- Stars
- 6.9k
- Forks
- 715
- Avg merge
- 2d 2h
- Merged PRs (30d)
- 11
Description
I'm sorry that I cannot produce a reproducible case here, but the complexity of the macro involved and my limited understanding of macros is prohibitive.
A description of the problem is:
- haxe.macro.Context.typeof() is documented thusly:
"Typing the expression may result in a compiler error which can be
caught using `try ... catch`."
However, if you actually catch an exception thrown by typeof in a macro, and handle it, the compiler will still exit with an error code after completing all of its subsequent work.
It feels like whatever coding within the compiler is associated with Context.typeof() sets some kind of compiler variable indicating that a fatal error ocurred which results in a error status code being returned by the compiler. But Context.typeof() says that you can catch errors and handle them. But having the compiler still error out anyway makes this kind of pointless.
I found that if I commented out line 2519 of typer.ml in my version of the compiler:
```
(* display_error ctx (error_msg err) p; *)
```
Then I was able to avoid the compiler erroring out.
Note that this line is being commented out near the end of the "type_ident" function of typer.ml.
My loose understanding is that type_ident is being invoked within the macro context, and yet whoever is invoking it is not setting the "ctx.on_error" function to a non-fatal version of that function, and instead allowing the default behavior of type errors being considered fatal to be invoked.
It is my belief that if a macro can catch an exception thrown by Context.typeof() and handle it, then the compiler should not return an error code. And yet, because type_ident is always considering type errors as fatal errors regardless of the context, this is not possible.
This is important to us because we run a macro over expressions that looks at typing and sometimes the Expr being examined cannot be detected as being an un-typable Expr (such as the "com" in "var a = com.foo.bar.MyClass"), but we can just catch the Context.typeof() exception and assume that we were looking at something without a type, and handle that case just fine. Except, the compiler still exits with an error code anyway, causing our build to unnecessarily fail.
Contributor guide
Assessment
This issue has not been assessed yet.