Useful 'line-too-long' suppression considered useless

[finite-state-machine]

Bug description

Consider:

# pylint: disable=missing-module-docstring,unused-argument
# pylint: disable=missing-function-docstring,unused-variable
# pylint: disable=too-many-arguments

# ruler:
# .......1.........2.........3.........4.........5.........6.........7....79->|

def first_case() -> None:
    # next line generates 'line-too-long' error (as it should)
    def my_function(aaa: int, bbb: int, ccc: int, ddd: int) -> int:  # pragma: no cover
        return 0

def second_case() -> None:
    # next line generates 'useless-suppression' (which is wrong)
    def my_function(aaa: int, bbb: int, ccc: int, ddd: int) -> int:  # pragma: no cover  # pylint: disable=line-too-long
        return 0

def third_case() -> None:
    # this case works as expected
    # pylint: disable-next=line-too-long
    def my_function(aaa: int, bbb: int, ccc: int, ddd: int) -> int:  # pragma: no cover
        return 0

def fourth_case() -> None:
    # this case works as expected
    def my_function(aaa: int, bbb: int, ccc: int, ddd: int, eee: int, fff: int, ggg: int) -> int:  # pragma: no cover  # pylint: disable=line-too-long
        return 0

# ruler again:
# .......1.........2.........3.........4.........5.........6.........7....79->|

Analyzing the above with --max-line-length=79 and --enable=line-too-long,useless-suppression, we get two errors, the first expected, and the second a surprise:

...:6:0: C0301: Line too long (87/79) (line-too-long)
...:11:0: I0021: Useless suppression of 'line-too-long' (useless-suppression)

As can be seen above, the second_case() function still triggers a useless-suppression warning, which shouldn't be issued: it's useful, as shown by first_case().

The fourth_case() shows that the issue is (probably) only triggered when it's a comment that makes the line too long.

This is related to #3368, but I've been asked to file this as a separate issue.

Configuration

No response

Command used

python3 -m pylint --rcfile=/dev/null  --max-line-length=79 --enable=line-too-long,useless-suppression

Pylint output

************* Module some_fliename
some_filename.py:6:0: C0301: Line too long (87/79) (line-too-long)
some_filename.py:11:0: I0021: Useless suppression of 'line-too-long' (useless-suppression)

------------------------------------------------------------------
Your code has been rated at 8.89/10 (previous run: 2.22/10, +6.67)

Expected behavior

The useless-suppression message should not be issued.

Pylint version

pylint 2.15.7
astroid 2.12.13
Python 3.8.12 (default, Jan 17 2022, 13:29:00)
[Clang 10.0.1 (clang-1001.0.46.4)]

OS / Environment

macOS 10.14
homebrew 3.5.10
pyenv 2.3.2

Additional dependencies

No response

[clavedeluna]

--max-line-length=79 not --max-line-len=79

[clavedeluna]

Reproduce with limited case (so it's not about an interaction with other code)

pylint test.py --max-line-length=79 --enable=line-too-long,useless-suppression

# pylint: disable=missing-module-docstring,unused-argument
# pylint: disable=missing-function-docstring,unused-variable

def second_case() -> None:
    # next line generates 'useless-suppression' (which is wrong)
    def my_function(aaa: int, bbb: int, ccc: int, ddd: int) -> int:  # pragma: no cover  # pylint: disable=line-too-long
        return 0

Interesting enough, I started to decrease --max-line-length value.... output differs:

 pylint test.py --max-line-length=60 --enable=line-too-long,useless-suppression
************* Module test
test.py:5:0: C0301: Line too long (64/60) (line-too-long)

pylint test.py --max-line-length=66 --enable=line-too-long,useless-suppression

-------------------------------------------------------------------
Your code has been rated at 10.00/10 (previous run: 6.67/10, +3.33)

Initial hunch is pylint is maybe ignoring # pragma: no cove

[finite-state-machine]

Apologies for the mistaken command-line flag (now fixed); thanks to @clavedeluna for pointing that out.

[finite-state-machine]

Initial hunch is pylint is maybe ignoring # pragma: no cover

That was my suspicion as well. Agreed that changing the option is more illustrative than adding the fourth case to exercise that behaviour.

[finite-state-machine]

I won't re-arrange things now to avoid confusion, but in future I'll take @clavedeluna's implied suggestion to include a minimal reproduction case as one script, and include other supporting/illustrative cases in a separate script.

[clavedeluna]

I think is is likely a special-case of #4802 and it seems like maintainers have decided not to fix it, but I"ll let them close this issue if that's the case since I wasn't part of that dicussion.

Or we can at least add functional tests to indicate this if they're not there

[finite-state-machine]

[Edit: This was phrased very poorly; please read this in the context of my clarification and apology two comments down.]

I can't accept that this is appropriate behaviour for pylint. Either the line warrants an error (in which case suppressing that error should not generate useless-suppression), or it does not warrant an error (in which case line-too-long should not be issued.) Either way, something has to change – and it's not the documentation.

[Pierre-Sassoulas]

@finite-state-machine you're welcome to fix the issue if you feel this is unacceptable. We have limited resources and 600+ issues. Maintainer's consensus is that the work involved is not worth the fix at the moment so no maintainer is going to work on it. But we'll review pull requests if there's any.

[finite-state-machine]

@Pierre-Sassoulas Please forgive my tone; I didn't mean that remark to come across as a criticism of the developers and maintainers, who have provided a wonderful tool and do excellent work. I truly appreciate all you've done and all you do.

It's entirely fair to say "we don't have the resources; but there's the code if you want to fix it". [Edit: It's more than fair, really, especially as you've graciously offered to entertain a pull request.]

What I meant to express – but phrased very poorly – was that the tool's behaviour isn't desirable in this case, i.e., that there is a functional bug, rather than a documentation bug. I didn't mean it to come across as a demand for action, although I can see that's how it reads.

I apologize unreservedly.

[DanielNoord]

I think it might indeed be difficult to solve this while not also changing the status quo as discussed in #4802. I'm not against fixing this but I'm against changing the status quo there..