--list-msgs and --list-msgs-enabled output different sets of messages

[scop]

Bug description

`--list-msgs` and `--list-msgs-enabled` output different sets of message ids; there are more in the latter.

Configuration

Default out of the box.

Command used

pylint --list-msgs | sed -rne 's/^:([^ ]+).*/\1/p' | sort -u > list-msgs
pylint --list-msgs-enabled | sed -rne 's/^  ([^ ]+).*/\1/p' | sort -u > list-msgs-enabled
diff -U0 list-msgs list-msgs-enabled

Pylint output

--- list-msgs	2021-07-31 11:18:23.627278871 +0300
+++ list-msgs-enabled	2021-07-31 11:19:05.295546080 +0300
@@ -42,0 +43 @@
+boolean-datetime
@@ -75,0 +77 @@
+continue-in-finally
@@ -133,0 +136 @@
+import-star-module-level
@@ -183,0 +187 @@
+long-suffix
@@ -218,0 +223 @@
+non-ascii-bytes-literal
@@ -239,0 +245,2 @@
+old-ne-operator
+old-octal-literal
@@ -269,0 +277 @@
+return-arg-in-generator

Expected behavior

No difference, same (complete) set of message ids output from both.

Pylint version

pylint 2.9.6
astroid 2.6.5
Python 3.8.10 (default, Jun  2 2021, 10:49:15) 
[GCC 9.4.0]

OS / Environment

No response

Additional dependencies

No response

[Pierre-Sassoulas]

The fix should be a refactor so we use the same list for both, which is not the case currently, one is handled in MessageStore, the other in Pylinter. (I don't think simply "fixing it" is enough)

    def cb_list_messages(self, option, optname, value, parser):
        """optik callback for printing available messages"""
        self.linter.msgs_store.list_messages()
        sys.exit(0)

    def cb_list_messages_enabled(self, option, optname, value, parser):
        """optik callback for printing available messages"""
        self.linter.list_messages_enabled()
        sys.exit(0)

[DanielNoord]

I investigated and this is due to list_messages checking for message.may_be_emitted() on line 78 in pylint/message/message_definition_store.py.
So, messages that cannot be emitted for you Python version are not shown in this list. Do we want to change this, thus showing all messages?

[Pierre-Sassoulas]

Well, now that you say it, the fix seems to be a better documentation of what list-msgs-enabled is doing compared to list-msg. It seems to me that this is working as intended, if the message cannot be emitted for this python interpreter it's not "enabled". What do you think @scop ?

[scop]

I do find the described behavior surprising. The way I'd personally like to see the options behave would be to make --list-msgs list everything, no matter if it can be emitted/not, and a new section in --list-msgs-enabled that lists non-emittable messages instead of bundling them in the list of disabled ones. But if that's not feasible/desirable, documenting the behavior would be the next best option.

[Pierre-Sassoulas]

Yes the name is not clear in itself. --list-emittable-messages and --list-messages seems more appropriate ? Renaming it is possible too, it would simply be a breaking change for 3.0.