WhatsApp / eqwalizer

A type-checker for Erlang
Apache License 2.0
506 stars 27 forks source link

Adding options to eqwalizer #37

Closed IndFer closed 1 year ago

IndFer commented 1 year ago

We would like to use eqwalizer in our whole repos for a while now (there is a huge number of them), but what is stopping us from doing so is that there is no existing option or way on how to exclude certain modules from type checking.

There are some existing modules that need to be skipped on type checking for various reasons. This way it is impossible to useeqwalizer since builds will fail.

Moreover, having another option on filtering error types would also be helpful. There is a set of error types that might need to be included/excluded from type checking.

Thank you!

VLanvin commented 1 year ago

Adding a module-level opt-out is something we could fairly easily add.

I'm a bit more curious in excluding errors from type checking, do you have any errors in mind? Hiding some of them may make the rest of the diagnostics fairly untrustworthy: in most cases, eqWAlizer will abort the type-checking if it encounters an error (e.g. unbound variable) and hiding it will make it seem like everything is OK when there could be another type error hidden.

IndFer commented 1 year ago

I meant eqWAlizer errors. For example _unknownid error might need to be excluded based in our needs.

ilya-klyuchnikov commented 1 year ago

For example unknown_id error might need to be excluded based in our needs.

Can you provide an example and explain the needs? thanks

IndFer commented 1 year ago

I will provide here a basic exmple, but what is important is the option for excluding modules from type checking. This is crucial at this point.

error: unknown_id
    │
    │       State :: rebar_state:t(),
    │                ^^^^^^^^^^^^^^^ Unknown id: rebar_state:t/0
tothlac commented 1 year ago

This is not the name of the module here where the problem was found. This is a type definition stored in rebar_state, but maybe it would be also good to add an option to eqwalizer to filter out messages, that we don't need. For example if it contains rebar_state:t, we don't want to see the message.

More important would be to filter out modules, so if the warning comes from a specific module, it should not be displayed. Maybe a new option in project.json , like this:

  "black_listed_modules": ["generated_module_.*"]}

We don't want to see those modules, because some of our modules are generated modules, but we trust in them. Let's say we have very good guarantees, that those generated modules are correct.

The other thing Indrit mentioned is to filter out messages based on their types. For instance I don't want to see messages belonging to redundant_fixme type, so having a new option in project.json would be able to solve this:

  "blacklisted_error_types" : ["redundant_fixme", ...]

We were only asking whether you are planning to implement something like the above mentioned filters in the near future, because for us it would be very useful to have these options.

tothlac commented 1 year ago

Actually we can also do this filtering in our rebar3 plugin, which will read the output of elp eqwalize-all and does this filtering for the error messages using simple string matching. The only problem we face here is that we can't easily separate the error messages from each other, because there are no obvious separator characters between the errors. Would it be possible to add a line containing only '*' characters so we can use it as a separator?

VLanvin commented 1 year ago

Regarding the additional options you mentioned, we have just released ELP, which is a much more complete version of the mini-elp bundled in this repository.

In particular, it features escape hatches such as -eqwalizer(ignore). that you can add to a module to opt it out of type-checking by eqWAlizer.

Since you are using rebar to load your project, the workflow should be exactly the same as when using mini-elp.