[red-knot] Specialize str.startswith for string literals

[sharkdp]

Summary

Infer precise Boolean literal types for str.startswith calls where the instance and the prefix are both string literals. This allows us to understand sys.platform.startswith(…) branches.

Test Plan

New Markdown tests

[github-actions]

mypy_primer results

Changes were detected when running on open source projects

pyinstrument (https://github.com/joerick/pyinstrument)
- warning[lint:possibly-unresolved-reference] /tmp/mypy_primer/projects/pyinstrument/pyinstrument/vendor/appdirs.py:99:33: Name `_get_win_folder` used when possibly not defined
- warning[lint:possibly-unresolved-reference] /tmp/mypy_primer/projects/pyinstrument/pyinstrument/vendor/appdirs.py:152:33: Name `_get_win_folder` used when possibly not defined
- warning[lint:possibly-unresolved-reference] /tmp/mypy_primer/projects/pyinstrument/pyinstrument/vendor/appdirs.py:319:33: Name `_get_win_folder` used when possibly not defined
- error[lint:unresolved-import] /tmp/mypy_primer/projects/pyinstrument/pyinstrument/vendor/appdirs.py:559:28: Module `ctypes` has no member `windll`
- error[lint:unresolved-import] /tmp/mypy_primer/projects/pyinstrument/pyinstrument/vendor/appdirs.py:562:20: Cannot resolve import `com.sun.jna`
+ warning[lint:unresolved-reference] /tmp/mypy_primer/projects/pyinstrument/pyinstrument/vendor/appdirs.py:99:33: Name `_get_win_folder` used when not defined
+ warning[lint:unresolved-reference] /tmp/mypy_primer/projects/pyinstrument/pyinstrument/vendor/appdirs.py:152:33: Name `_get_win_folder` used when not defined
+ warning[lint:unresolved-reference] /tmp/mypy_primer/projects/pyinstrument/pyinstrument/vendor/appdirs.py:319:33: Name `_get_win_folder` used when not defined
- Found 292 diagnostics
+ Found 290 diagnostics

[sharkdp]

The pyinstrument changes show that we now understand the sys.platform.startswith('java') branch in that file. We still report some diagnostics, because the reachable else branch sets system = sys.platform and then uses that symbol inside nested scopes for further platform checks. We still emit errors in those branches, because the public type of system is Literal["linux"] | Unknown, so we don't infer those platform check branches as unreachable.

So I think those diagnostics are true positives according to our model, where system could be reassigned (not that we would understand that yet, but we would require that symbol to be qualified with Final).

Two false positives further down in the file are now gone, because they use system for platform checks inside the scope it was defined in.

[AlexWaygood]

It might be confusing for users if we infer precise types for str.startswith but not str.endswith — should we do that method too?

Overall I'm okay with this, but note that this goes beyond what the spec requires of us when it comes to understanding sys.platform branches

[sharkdp]

It might be confusing for users if we infer precise types for str.startswith but not str.endswith — should we do that method too?

It's going to be extremely rare that someone actually calls x.startswith(y) where both x and y are string literal types. I don't think that we have to worry about similarly precise endswith inference being a required feature for anyone.

Overall I'm okay with this, but note that this goes beyond what the spec requires of us when it comes to understanding sys.platform branches

Overall I'm okay with this, but note that this goes beyond what the spec requires of us when it comes to understanding sys.platform branches

Yes, but the spec is vague. And there is this issue which aims to improve the spec. It includes this comment:

Maybe it would also make sense to support platform checks using startswith(), as that is officially recommended in the Python docs, and is required to properly support some Unix variants, like FreeBSD, that include the version number in the platform string. See also python/typeshed#11876.

And this comment:

mypy has actually always supported sys.platform.startswith, since 2016 (in addition to == and !=)

And this:

sys.platform.startswith probably makes sense to add since it helps FreeBSD (a Tier 3 platform), is already supported by mypy, and doesn't seem difficult to add to other type checkers.