Closed benmerckx closed 6 years ago
Can you provide an example?
And did you try disabling additional features? Unlike null safety checks, those features transform AST:
--macro Safety.enable('my.pack', false); //`false` disables everything except null safety
Oh, i think i misunderstood.
If your build macros generate additional code in classes which are being checked, you can wrap that code in (generated_expr:Unsafe<T>)
to skip checking of autogenerated expressions.
I'm not sure If such code can be excluded from null safety easily based on expr positions. I will investigate that later.
Well in this case I use tink_sql which lets you build a Database by extending tink.sql.Database, which triggers an @:autoBuild macro. This fails with:
.../tink/sql/macros/DatabaseBuilder.hx:61: characters 35-39 : Safety: Cannot use "this" until all instance fields are initialized.
Because the generation is external I'm looking for a way to bypass the warning, but keep warnings for code I manage myself.
Can you please assemble a simple project with tink_sql? I've never used it myself.
I've managed to exclude expressions with "external" positions from null safety.
But that will not work if a macro manually generates positions to point to the place where a macro was called. For such cases I've added @:safety(unsafe)
meta, which you can use to annotate classes or fields to exclude them from null safety (see readme).
Wow, great!
Enabling safety for my code base triggers warnings in code generated by (build) macros from an external library (the pos info also points to the external macro file). Is there any way to disable those or is that not feasible? Or would I need to implement that through
Safety.plugin.onComplete
?