Fix issues when inferring match variables

[cdce8p]

Description

Add assigned_stmts functions to MatchMapping, MatchStar, and MatchAs. Except for the most basic case (bare MatchAs), they return util.Uninferable. This will fix the crashes.

Inferring anything more will require checking if a case pattern can be matched at all, and if it can which part of the pattern matches which of the subject. That isn't implement (yet).

# Code used for validation that pylint doesn't crash

msg = 42
match msg:
    case (1, *rest):
        if rest != 2:
            pass
    case {1: _, **rest2}:
        if rest2 != 2:
            pass
    case y:
        if y != 2:
            pass

Type of Changes

	Type
✓	🐛 Bug fix

Related Issue

Ref pylint-dev/pylint#4685
Ref pylint-dev/pylint#4686

[Pierre-Sassoulas]

Looks good, I hope it can go in astroid 2.6.3. Thank you for fixing the crash and pave the way for the proper inference to be implemented.

[Pierre-Sassoulas]

Should be py38_plus from consts :)

[cdce8p]

if PY38_PLUS can't be inferred by mypy. I added not PY310 to the test cases but that's about it what will work.

[Pierre-Sassoulas]

I don't understand, what is the problem with mypy ?

[cdce8p]

mypy doesn't really infer if an if-block is reachable. It only checks specific conditions one of them being sys.version_info. https://mypy.readthedocs.io/en/stable/common_issues.html#python-version-and-system-platform-checks

Btw we had a similar issue with the overload-guard in astroid/rebuilder.py. See #1069

--
For tests PY310_PLUS and so on are fine, but for everything else directly using sys.version_info would be my preferred way of doing it. Although there is no need to replace all current occurrences, just if / when it makes sense, i.e. to fix some typing issue.

[Pierre-Sassoulas]

We could remove the constant entirely in another MR if they do not make sense (well if they're making mypy worse). Originally I refactored because a single constant is better than n constants with the same name in n files.

[cdce8p]

In most cases they don't change anything. Just here and for the aforementioned overloads in astroid/rebuilder.py. I think we have more important things to do than to remove these.

[Pierre-Sassoulas]

We sure do (but those kind of refactor take a single keystroke in pycharm)

[cdce8p]

Looks good, I hope it can go in astroid 2.6.3.

From my point of view, this PR is ready and can be merged.

Thank you for fixing the crash and pave the way for the proper inference to be implemented.

I do have some ideas how to do it, but still have to think about if it would work. So will probably take a while.