Provide a means to enable/disable the ignore error quick-fix.

[pq]

At least, @scheglov doesn't want it on all the time. :)

One thought is to add a new analysis option

server:
  enable-ignore-fixes: true

or more generally:

server:
  quick-fix:
    ignore_errors: enable

(though that suggests that we can configure other fixes this way and I'm not sure we want to.)

Ideally this could be done at a workspace-level I think but we don't have precedent for that.

@bwilkerson : thoughts?

[scheglov]

Probably for some time it would be the only quick-fix to enable / disable.
But I can imagine having more... hm... controversial fixes :-)
So, the more general solution would be better IMHO.

[bwilkerson]

IMO, the fewer knobs to control the system the better.

This fix also has implications for Atom, which displays an icon for all errors with which a fix is associated. Now it will need to display the icon on all errors.

[pq]

IMO, the fewer knobs to control the system the better.

👍

But where do you stand on this proposed one? The downside to not having this fix is that users can't reasonably find error codes associated with errors if they legitimately want to ignore them. On the other hand, the downside to having the fix is that the feature may be abused and/or folks generally confused.

One suggestion was to further constrain what errors have ignore fixes associated but I'm not sure how sustainable or effective that would be...

This fix also has implications for Atom, which displays an icon for all errors with which a fix is associated. Now it will need to display the icon on all errors.

@devoncarew and I chatted about this. I think that icon should be reserved for more substantial fixes and so, no, it shouldn't appear on ones with only an ignore option.

[bwilkerson]

But where do you stand on this proposed one?

I'm not sure. While I understand that it's hard to ignore errors without it, I think that most errors should not be ignored most of the time. Limiting which errors have this quick fix is only as good as a workaround as we are at figuring out which errors people want to ignore.

I have to wonder whether we ought to be looking at a different mechanism for implementing this (though I'm not sure what it would be).

[pq]

@Hixie: do you have a rough sense for what (or how many) warnings you're wanting to suppress? Are there many besides what I see special-cased in the analyze command?

[Hixie]

Ideally we wouldn't suppress any. If any are suppressed, it would normally be as a temporary workaround for an analyzer bug.

I imagine tests might suppress some warnings e.g. about using @Protected members that they want to call as part of a test, but even there I would expect it to be rare.

[alexander-doroshko]

IMHO analysis option like ignore_errors: enable doesn't solve the issue. Use case is: in 99% cases I do not want to see 'suppress' quick fix, but in 1% I need to be able to invoke it. With analysis option when I want to suppress warning, I'd need to go edit analysis option, reanalyze, return to warning, invoke quick fix, go back disable the option. Too many steps.

In IntelliJ's Java support this problem is solved by placing 'suppress' action to the secondary menu of each Quick Fix (to open it user has to press Right-arrow).

So we can think about solving this issue at IDE side without introducing analysis options. Second-level menu doesn't work for warnings that have no quick fixes, because there's no first level menu, so their 'suppress' will have to remain on 1st level.

Also if we go this way, we need to handle places with several warnings in one place, we'll need to understand which Quick Fixes correspond to which warning and how to handle when one warning has quick fixes, but another one - doesn't.

Conclusion: I do not have ideal solution for the issue, but I think solution should be searched for in the IDE's User Interface area.

[devoncarew]

I think exposing the suppress option just at the IDE level makes sense. Are the error code we'd need to use passed along in the error information? I see severity, type, and message on AnalysisError, but not a code.

[bwilkerson]

Are the error code we'd need to use passed along in the error information?

No, not currently. I was hoping to get to where we had stable error codes before adding them, but perhaps we need to make them visible now anyway.

[pq]

I like doing it at the IDE level and really like what IntelliJ does. Cheers @alexander-doroshko!

No, not currently. I was hoping to get to where we had stable error codes before adding them, but perhaps we need to make them visible now anyway.

This sounds like a good plan. No hiding from the fact that folks are starting to depend on these codes... Happy to help on this front.

In the meantime, I'll remove the current quick-fixes.