Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding options to eqwalizer #37

Closed
IndFer opened this issue Jul 26, 2023 · 7 comments
Closed

Adding options to eqwalizer #37

IndFer opened this issue Jul 26, 2023 · 7 comments

Comments

@IndFer
Copy link

IndFer commented Jul 26, 2023

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 use_eqwalizer_ 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
Copy link
Contributor

VLanvin commented Jul 27, 2023

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
Copy link
Author

IndFer commented Jul 27, 2023

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

@ilya-klyuchnikov
Copy link
Member

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
Copy link
Author

IndFer commented Jul 27, 2023

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
Copy link

tothlac commented Jul 27, 2023

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
Copy link

tothlac commented Jul 27, 2023

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
Copy link
Contributor

VLanvin commented Aug 7, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants