Reconsider the necessity of ReportPass

[aviatesk]

While working on #543 I realized that the current design of ReportPass might not be functioning as effectively as hoped. Originally, ReportPass was meant to allow users well-versed in JET internals to completely ignore specific reports, thereby deleting associated calculations (which can not be achieved by filtering out reports after the analysis has been completed). However, there seems to be a lack of such advanced users at present, and this is inadvertently increasing the complexity of the code base, potentially discouraging potential contributors. It might be beneficial to shift towards a simpler configuration style that can control specific behaviors of the analysis with in the short term.

[nantiamak]

We're thinking of using ReportPass to create a custom report mode that combines mode:=typo with MethodErrors. Our codebase is quite large and when running JET on mode:=basic, we've noticed that we can get a non-negligible number of false positives. Thus, we were hoping to create this custom report to restrict the analysis to the errors that are most important to us.
So, I was wondering whether the plan is still to deprecate ReportPass in the future.
If that's the case, then would you consider adding an intermediate mode between typo and basic that generates MethodError as well?

[aviatesk]

Hello. Sorry for the delayed response.
Currently, I plan to deprecate ReportPass and reimplement it as ReportConfig, which will have a simpler interface. Even with ReportConfig, it should still be possible to implement a new configuration that reports MethodError in addition to those reported with :typo-mode.

[nantiamak]

Thanks for the reply @aviatesk!