Community
Participate
Working Groups
3.4 Similar to API tooling offering a filtering mechanism for certain API violation diagnostics, the platform should offer a base mechanism which could be leveraged in JDT to hire certain instances of compiler warnings for instance. Note that this functionality should not just hide some existing markers, but rather remember these filters so that a builder could consult the list of filters to avoid producing offending markers (in case of a clean build, there may not be any preexisting marker).
Also note that these filters should be shareable along with the source code (like using preference store).
Philippe, the same would then also be needed for JDT Core's problem reporting during reconcile because otherwise the suppressed marker would appear in the editor as (temporary) problem.
See bug 156710 comment 10: > And the hard thing is not how to suppress a specific warning, but how to update > these external annotations when the targeted code changes. The solution would > probably have to listen to text file buffers, add positions to the documents, > and update/delete the positions when the text is changed. An unsolved problem > is how to transfer external annotations when text is moved (e.g. by > drag-and-drop or by refactorings such as extract method, move, pull up, ...) Class PositionTracker in org.eclipse.search already implements parts of this to update search results when files are modified. API problem filters have the same problem, see bug 226470.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
