Description
Bug Report
I encountered a potential caching issue when using dmypy to type-check in-command code string. The issue arises when executing commands with dmypy run -- -c <code>. As shown below, the second command should not produce an error, as the assignment is correct (int to int). However, it seems like the daemon is caching the previous state incorrectly, leading to an error.
I understand that using dmypy in this manner is not typical, as it is primarily designed to be a long-running daemon process, which allows to perform type checking more efficiently by caching state. However, the documentation states that "You can use almost arbitrary mypy flags after --", which suggests that this usage should be supported. This might lead to misunderstandings or confusion about the expected behavior when using inline code execution with dmypy. Additionally, any tooling that leverages the -c option in dmypy for inline type checking will be impacted by this behavior, potentially causing issues in automated workflows and integrations.
To Reproduce, and Actual Behavior
$ dmypy run -- -c "a:str=1"
<string>:1: error: Incompatible types in assignment (expression has type "int", variable has type "str") [assignment]
Found 1 error in 1 file (checked 1 source file)
$ dmypy run -- -c "a:int=1"
<string>:1: error: Incompatible types in assignment (expression has type "int", variable has type "str") [assignment]
Found 1 error in 1 file (checked 1 source file)
Expected Behavior
$ dmypy run -- -c "a:int=1" # second time
Success: no issues found in 1 source file
Your Environment
- Mypy version used: 1.13.0
- Python version used: 3.12.3