Ref#19274This is a bit ugly. But I propose to have this "hot-fix" until we have aproper overhaul of instance vs class variables. To be clear: attributeaccess already works correctly (on both `P` and `Type[P]`), butsubtyping 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 areerroneously marked as unused in re-runs of dmypy. There are also caseswhere errors disappear on the re-run.As far as I can tell, this only happens in modules which contain animport that we don't know how to type (such as a module which does notexist), and a submodule which is unused.There was a lot of commenting and investigation on this PR, but I hopethat 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 containthe drive letter colon for Windows machines.Fixes#19335.This is done by changing how `find_node` works slightly, allowing thereto be at most two colon (`:`) characters in the passed key for windowsmachines 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 AttributeErrorwhen:* Some paths in the try block return while others don't* The non-return path is executed at runtime* No further await calls are neededThis occurred because mypyc's IR requires all control flow paths toassignto spill targets. The non-return path assigns NULL to maintain thisinvariant, but reading NULL attributes raises AttributeError in Python.Modified the GetAttr IR operation to support reading NULL attributeswithout raising AttributeError through a new allow_null parameter. Thisparameter is used specifically in try/finally resolution when readingspill targets.* Added allow_null: bool = False parameter to GetAttr.init inmypyc/ir/ops.py* When allow_null=True, sets error_kind=ERR_NEVER to preventAttributeError* Modified read_nullable_attr in IRBuilder to create GetAttr withallow_null=True* Modified try_finally_resolve_control in statement.py to useread_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 toget_attr_with_allow_null* get_attr_with_allow_null reads attributes without NULL checks and only    increments reference count if not NULLDesign 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 targetsto 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 takingthe non-return path through the try block.Seemypyc/mypyc#1115

…it (#19353)When a try/finally block in an async function contains an await statementin the finally block, exceptions raised in the try block are silentlyswallowed if a context switch occurs. This happens because mypyc storesexception 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 swallowingThe 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 expressionsImplementation 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 expressionsTest 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 originalSeemypyc/mypyc#1114.

…ally clauses. (#19270)Fixes#19269This PR refactors the logic implemented in#19118 (which only targetedrepeatedly checked loops) and applies it to repeatedly checked finallyclauses.I moved nearly all relevant code to the class `LoopErrorWatcher`, whichnow has the more general name `IterationErrorWatcher`, to avoid codeduplication. However, one duplication is left, which concerns errorreporting. 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 importingis acceptable in such cases (both for Mypy and Mypyc).After the refactoring, it should not be much effort to apply the logicto other cases where code sections are analysed iteratively. However,the only thing that comes to my mind is the repeated checking offunctions with arguments that contain constrained type variables. I willcheck it. If anyone finds a similar case and the solution is as simpleas 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 nowrelies on collecting the original type objects instead of parts ofpreliminary `revealed_type` notes. As@JukkaL suspected, this approachis much more straightforward than introducing a sufficiently complete`revealed_type` note parser.Please note that I appended a commit that refactors already existingcode. It is mainly code-moving, so I hope it does not complicate thereview of this PR.

Add a few sections and do some editing.