Community
Participate
Working Groups
Build Identifier: 20110615-0604 The exlusion filters for the code analysis problems are not working correctly. Neither excluding a complete path or a single file leads to the respective file(s) being skipped in the code analysis - neither when simply opening the file or starting code analysis on a folder through the context menu. Reproducible: Always Steps to Reproduce: 1. Add an error to an existing file (e.g. type std::vector<int> temp; temp.clear(10);) 2. Exclude the file from the respective code analysis filter (in the example: "invalid arguments" filter) 3. Remove the shown error from the list of problems 4. Close the file 5. Open the file again => error will be shown again even though the file was excluded from code analysis.
This is still true in Eclipse 4.4 (i.e. CDT 8.4.0) The problem lies in function org.eclipse.cdt.codan.core.param.FileScoreProblemPreferences.matchesFilter that receive file path with leading '/' (Unix's directory separator) and that the ui does not accept file pattern for exclusion beginning with '/'.
(In reply to Jean-Christophe Weill from comment #1) > This is still true in Eclipse 4.4 (i.e. CDT 8.4.0) > > The problem lies in function > org.eclipse.cdt.codan.core.param.FileScoreProblemPreferences.matchesFilter > > that receive file path with leading '/' (Unix's directory separator) and > that the ui does not accept file pattern for exclusion beginning with '/'. And one (dirty) solution was to edit org.eclipse.cdt.codan.internal.ui.dialogs.ExclusionInclusionEntryDialog.java then I commented lignes 173 to 175 if (path.isAbsolute() ...) { } So this allows now absolute path and now Filters can match! I use filter like /**/src/foo.cpp instead of **/src/foo.cpp -- JC
Seeing something as trivial failing to work properly on Linux, especially after 3 years from the first report is a bit sad );
If you really need it fixed, you are welcome to submit a path to CDT using a proper channel - gerrit reviews https://wiki.eclipse.org/CDT/contributing
That's of course true, but I'd have to know java and Eclipse's internals to do so, and neither of these is the case here...
New Gerrit change created: https://git.eclipse.org/r/43344
There were two mismatches between the pattern in the exclusion filter, and the resource path being tested against it: - The first was relative to the workspace root, while the second was relative to the filesystem root. I fixed this by making the second relative to the workspace root as well, by using IResource.getFullPath() instead of IResource.getLocation() to obtain it. - The resource path had a leading slash (i.e. was an absolute path, even with my first change), while the pattern didn't (i.e. was a relative path). I fixed this by calling makeRelative() on the resource path, making it a relative path.
Great - I hope this change will make it to the next release! Thanks a lot!
Gerrit change https://git.eclipse.org/r/43344 was merged to [master]. Commit: http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=5d2f7bcb56bc4d61a97e2c248d8c573540cc80a5
New Gerrit change created: https://git.eclipse.org/r/43378
Gerrit change https://git.eclipse.org/r/43378 was merged to [master]. Commit: http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=d755ace3ccfa19a7ca654df494b6704cf70aac34
