sobolevn / flake8-eradicate / 341

100%

push

travis-ci-com

Resolves Issue #103 noqa comments (#106)

* Add false positive test for noqa comment

`flake8-eradicate` raises a violation when a `# noqa` comment is defined
inside of a multi-line docstring. `eradicate` itself does not raise this
as a violation.

It should not be detected as a violation, because it is also normal way
to suppress `flake8` violations (like DAR201) in multi-line docstrings.

As @sobolevn points out, this is probably related to the use of
`physical_line` rather than `logical_line`.
https://github.com/sobolevn/flake8-eradicate/issues/103#issuecomment-563953533

This commit adds a function definition to the `correct.py` fixture
that has a multi-line docstring and a `# noqa` comment defined inside of
it.

* Check if comment in physical line before eradicate

When passing a physical line to eradicate, we need to make sure this
line contains a comment (as per Python definition). Otherwise this
could lead to documentation or noqa-comments in multi-line docstrings as
being interpreted as a comment. This is probably caused by passing a
single physical line to the eradicate function
`filter_commented_out_code`, while this function expects a whole file as
input. When passing a whole files source into the
`filter_commented_out_code` can parse the logical structure it self.

Since we are removing the context for the `filter_commented_out_code`
function, we need to make sure the passed in line actually contains a
comment. This is a test, that would usually happen inside of `eradicate`
but requires more context.

To test if the physical line contains a comment, we can request the
`tokens` of the current physical line from `flake8` to be passed in.
The tokens allow to pre-check if the physical line actually contains
a comment. The eradicate function is only invoked for physical lines
that do contain a comment.

* Rename function and add docstring

The function `_is_equal_source` is renamed to
`_contains_commen... (continued)

10 of 10 branches covered (100.0%)

Branch coverage included in aggregate %.

14 of 14 new or added lines in 1 file covered. (100.0%)

42 of 43 relevant lines covered (97.67%)

1.95 hits per line