Ref #19274

This is a bit ugly. But I propose to have this "hot-fix" until we have a
proper overhaul of instance vs class variables. To be clear: attribute
access already works correctly (on both `P` and `Type[P]`), but
subtyping returns false because of
```python
                elif (IS_CLASSVAR in subflags) != (IS_CLASSVAR in superflags):
                    return False
```

There is currently a misbehaviour where "type: ignore" comments are
erroneously marked as unused in re-runs of dmypy. There are also cases
where errors disappear on the re-run.

As far as I can tell, this only happens in modules which contain an
import that we don't know how to type (such as a module which does not
exist), and a submodule which is unused.

There was a lot of commenting and investigation on this PR, but I hope
that the committed tests and fixes illustrate and address the issue.

Related to #9655

---------

Co-authored-by: David Seddon <david@seddonym.me>
Co-authored-by: Shantanu <12621235+hauntsaninja@users.noreply.github.com>
Co-authored-by: Ivan Levkivskyi <levkivskyi@gmail.com>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

In this pull request, we allow dmypy suggest absolute paths to contain
the drive letter colon for Windows machines. Fixes #19335.

This is done by changing how `find_node` works slightly, allowing there
to be at most two colon (`:`) characters in the passed key for windows
machines instead of just one like on all other platforms, and then using
`rsplit` and a split limit of 1 instead of just `split` like prior.

---------

Co-authored-by: Stanislav Terliakov <50529348+sterliakov@users.noreply.github.com>

…hs (#19361)

Async functions with try/finally blocks were raising AttributeError
when:

* Some paths in the try block return while others don't
* The non-return path is executed at runtime
* No further await calls are needed

This occurred because mypyc's IR requires all control flow paths to
assign
to spill targets. The non-return path assigns NULL to maintain this
invariant, but reading NULL attributes raises AttributeError in Python.

Modified the GetAttr IR operation to support reading NULL attributes
without raising AttributeError through a new allow_null parameter. This
parameter is used specifically in try/finally resolution when reading
spill targets.

* Added allow_null: bool = False parameter to GetAttr.init in
mypyc/ir/ops.py
* When allow_null=True, sets error_kind=ERR_NEVER to prevent
AttributeError
* Modified read_nullable_attr in IRBuilder to create GetAttr with
allow_null=True
* Modified try_finally_resolve_control in statement.py to use
read_nullable_attr
  only for spill targets (attributes starting with 'mypyc_temp')
* Updated C code generation in emitfunc.py:
* visit_get_attr checks for allow_null and delegates to
get_attr_with_allow_null
* get_attr_with_allow_null reads attributes without NULL checks and only
    increments reference count if not NULL

Design decisions:

* Targeted fix: Only applied to spill targets in try/finally resolution,
not a general replacement for GetAttr. This minimizes risk and maintains
  existing behavior for all other attribute access.

* No initialization changes: Initially tried initializing spill targets
to Py_None instead of NULL, but this would incorrectly make try/finally
  blocks return None instead of falling through to subsequent code.

Added two test cases to mypyc/test-data/run-async.test:

* testAsyncTryFinallyMixedReturn: Tests the basic issue with async
  try/finally blocks containing mixed return/non-return paths.

* testAsyncWithMixedReturn: Tests async with statements (which use
  try/finally under the hood) to ensure the fix works for this common
  pattern as well.

Both tests verify that the AttributeError no longer occurs when taking
the non-return path through the try block.

See mypyc/mypyc#1115

…it (#19353)

When a try/finally block in an async function contains an await statement
in the finally block, exceptions raised in the try block are silently
swallowed if a context switch occurs. This happens because mypyc stores
exception information in registers that don't survive across await points.

The Problem:

- mypyc's transform_try_finally_stmt uses error_catch_op to save exceptions
- to a register, then reraise_exception_op to restore from that register
- When await causes a context switch, register values are lost
- The exception information is gone, causing silent exception swallowing

The Solution:

- Add new transform_try_finally_stmt_async for async-aware exception handling
- Use sys.exc_info() to preserve exceptions across context switches instead
- of registers
- Check error indicator first to handle new exceptions raised in finally
- Route to async version when finally block contains await expressions

Implementation Details:

- transform_try_finally_stmt_async uses get_exc_info_op/restore_exc_info_op
- which work with sys.exc_info() that survives context switches
- Proper exception priority: new exceptions in finally replace originals
- Added has_await_in_block helper to detect await expressions

Test Coverage:

Added comprehensive async exception handling tests:

- testAsyncTryExceptFinallyAwait: 8 test cases covering various scenarios
    - Simple try/finally with exception and await
    - Exception caught but not re-raised
    - Exception caught and re-raised
    - Different exception raised in except
    - Try/except inside finally block
    - Try/finally inside finally block
    - Control case without await
    - Normal flow without exceptions
- testAsyncContextManagerExceptionHandling: Verifies async with still works
    - Basic exception propagation
    - Exception in **aexit** replacing original

See mypyc/mypyc#1114.

…ally clauses. (#19270)

Fixes #19269

This PR refactors the logic implemented in #19118 (which only targeted
repeatedly checked loops) and applies it to repeatedly checked finally
clauses.

I moved nearly all relevant code to the class `LoopErrorWatcher`, which
now has the more general name `IterationErrorWatcher`, to avoid code
duplication. However, one duplication is left, which concerns error
reporting. It would be nice and easy to move this functionality to
`IterationErrorWatcher`, too, but this would result in import cycles,
and I am unsure if working with `TYPE_CHECKING` and postponed importing
is acceptable in such cases (both for Mypy and Mypyc).

After the refactoring, it should not be much effort to apply the logic
to other cases where code sections are analysed iteratively. However,
the only thing that comes to my mind is the repeated checking of
functions with arguments that contain constrained type variables. I will
check it. If anyone finds a similar case and the solution is as simple
as expected, we could add the fix to this PR, of course.

…st manner. (#19324)

This PR fixes a regression introduced in #19118 and discussed in #19270.
The combination of the revealed types of individual iteration steps now
relies on collecting the original type objects instead of parts of
preliminary `revealed_type` notes. As @JukkaL suspected, this approach
is much more straightforward than introducing a sufficiently complete
`revealed_type` note parser.

Please note that I appended a commit that refactors already existing
code. It is mainly code-moving, so I hope it does not complicate the
review of this PR.