some pylint messages which contain numbers fail to match
praiskup opened this issue · comments
Examples:
- Too many {lines, ...} in module (1192/1000)
- Redefining name 'xxx' from outer scope (line 1)
What would be better, to allow passing custom filter rules on commandline,
or would it be possible to filter-out the line numbers from error messages directly?
Or some csdiff --pylint
?
It should be as easy as appending a message filter here:
https://github.com/kdudka/csdiff/blob/e314e401/csfilter.cc#L92
The filter can be specific for a particular checker, which avoids the need to enable it explicitly. Please attach the output of the real-world scan, where the defects should have been matched but they were not. I would like to include it as a regression test for the fix in question.
Note that the filenames in the reports are somewhat artificial... csdiff would
misparse the reports if they were relative. Se even though pylint prints
copr_frontend/something
we artificially prepend leading /
so csdiff can
successfully parse that. Is this worth another issue?
edit: The pylint output we use is is --msg-template='/{path}:{line}:{column}: {msg_id}[pylint]: {msg}'
I looked at csdiff supported format, and we can probably switch to json.
So I'm attaching new example of old.log and new.log in json format.
When I do csdiff -c old.log new.log
, I'd prefer that only the first error
could stay printed (a long line was too long before, and is too long
even now, but user really should wrap the long line now - when touching
the code...). If that's too pedantic - all can be hidden:
$ csdiff -c old.log new.log
Error: PYLINT:
coprs_frontend/alembic/versions/24e9054d4155_fix_results_paths.py:24: C0301(line-too-long): Line too long (132/120)
Error: PYLINT:
coprs_frontend/coprs/logic/builds_logic.py:1: C0302(too-many-lines): Too many lines in module (1192/1000)
Error: PYLINT:
coprs_frontend/coprs/logic/coprs_logic.py:131:36: W0621(redefined-outer-name): CoprsLogic.set_query_order: Redefining name 'desc' from outer scope (line 7)
Error: PYLINT:
coprs_frontend/coprs/models.py:1: C0302(too-many-lines): Too many lines in module (1783/1000)
Another one which is just moving across one file when something is added:
Error: PYLINT:
coprs_frontend/coprs/helpers.py:551:23: W0621(redefined-outer-name): raw_commit_changes: Redefining name 'text' from outer scope (line 381)
Note that the filenames in the reports are somewhat artificial... csdiff would
misparse the reports if they were relative. Se even though pylint prints
copr_frontend/something we artificially prepend leading / so csdiff can
successfully parse that. Is this worth another issue?
Yes, please. I was not able to reproduce it myself.
So I'm attaching new example of old.log and new.log in json format.
Looks good. Could you please use "checker": "PYLINT_WARNING"
instead of "checker": "PYLINT"
?
For historical reasons we use the ${TOOL}_WARNING
scheme to name checkers in reports that do not come from Coverity.
Note that the filenames in the reports are somewhat artificial... csdiff would
misparse the reports if they were relative.
[..] Is this worth another issue?Yes, please. I was not able to reproduce it myself.
I neither can now :-( I probably did something wrong before. Sorry for noise.
Btw., csdiff can not parse output of csdiff -c old.json.err new.json.err
. But
that's probably expected?
Looks good. Could you please use "checker": "PYLINT_WARNING" instead of "checker": "PYLINT"?
Sure, I guess we have to :-)
I just checked the patch works fine, thank you!
Do you plan to wrap new release, and update Fedora (at least rawhide)?
Another pattern:
Error: PYLINT_WARNING:
coprs_frontend/tests/test_views/test_coprs_ns/test_coprs_general.py:706:8: W0404(reimported): TestCoprRepoGeneration.test_works_on_older_builds: Reimport 'app' (imported line 13)
so apparently another form but with imported
keyword :(
Btw., csdiff can not parse output of csdiff -c old.json.err new.json.err. But that's probably expected?
I am not able to reproduce this either. Could you please file a separate issue with some steps to reproduce it?
so apparently another form but with imported keyword :(
Thank you for reporting it! Should be fixed with 5a3e60c.
Do you plan to wrap new release, and update Fedora (at least rawhide)?
I did not plan to but it is quite easy, so why not :-)
https://koji.fedoraproject.org/koji/buildinfo?buildID=1500055
Thanks for the quick fix, and release!
I am not able to reproduce this either. Could you please file a separate issue with some steps to reproduce it?
Reported in #7.