is there potential for false positives here? @hubertp, what do you think?
my hope is that the reporter only counts errors that are actually reported.
the long term solution here would be to make sure "silent" is actually silent. asking the compiler if something type-checks should be one of the services that the compiler provides.
right, that sounds like a bug in silent
I was also worried about other errors being reported, not the one you're looking for.
Maybe you can look into the buffer for the specific error that's relevant here? Or maybe that could be another nice feature.
not sure if reporters store the errors. i know that contexts do, but we don't have access to the context here (well, not to the one in which the error is reported, this one stems from a lazy type).
i'm not too worried because cyclic references are the only kind of errors that are not silenced properly. if you get a cyclic reference type-checking "a = expr", we hope that it's related to "a". i agree it could be unrelated in principle.
cyclic errors are not covered by the silent by design. Reporter only counts (or at least should) the errors that are reported, that's correct.
It seems that the best way would be to always catch the cyclic error, log it in the buffer and re-throw, though I don't know what would be the performance impact (probably negligible since it only happens on a real error).
If "silent" would actually throw the cyclic reference, that solve my problem here. but what happens is that I call "silent(typed(someTree))", and somebody catches and reports the cyclic reference.
so, maybe we can have a flag like reportAmbiguous that allows us to switch between those behaviours?
although I should add that boolean flags are bad according to some :-)
I think there are too many flags around already. I will have a look and see why is it reported in the first place.