Refactor --list-msgs & --list-msgs-enabled

[DanielNoord]

• Add yourself to CONTRIBUTORS if you are a new contributor.
• Add a ChangeLog entry describing what your PR does.
• If it's a new feature, or an important bug fix, add a What's New entry in
  doc/whatsnew/<current release.rst>.
• Write a good description on what the PR does.

Type of Changes

	Type
✓	✨ New feature
✓	🔨 Refactoring

Description

Both options now show which messages can't be emitted with the current interpreter. This makes function more like their name implies. Code clearly shows in which order/format the messages are emitted.
This closes #4778

[coveralls]

Coverage increased (+0.01%) to 92.587% when pulling 09b6f99 on DanielNoord:list-msgs into 741276e on PyCQA:main.

[Pierre-Sassoulas]

Nice job ! Could we refactor a little further and create a common function to recover emitable/non-emittable ? This way list_messages_enabled would loop on the result of this function and the other one would use them directly.

[Pierre-Sassoulas]

Nice refactor 👍

[DanielNoord]

Where should I put this common function? Is there a good place for utils function for files in different directories?

Thinking of:

def find_emittable_messages(
    messages: List[MessageDefinition],
) -> Tuple[List[MessageDefinition], List[ValuesView[MessageDefinition]]]:
    emittable = []
    non_emittable = []
    for message in messages:
        if message.may_be_emitted():
            emittable.append(message)
        else:
            non_emittable.append(message)
    return emittable, non_emittable

[Pierre-Sassoulas]

MessageDefinitionStore is the logical place so you don't have to provide the messages (they're already a class attribute).

[Pierre-Sassoulas]

Thank you !

[scop]

FYI, my recent pylint bash completion PR at scop/bash-completion#562 is what triggered to me to file #4778. Looking at the code here it seems my scraper would be still doing the right thing after these changes, cool.

The scraper is far from pretty, but all things considered I don't think we have a better choice at the moment, and if we want to support old pylint versions out there, new additions of e.g. better machine parseable outputs for these in new releases wouldn't help either.