[ty] Add hint if async context manager is used in non-async with statement

[lipefree]

Summary

Implements astral-sh/ty#508, considering the following code :

class Manager:
    async def __aenter__(self): ...
    async def __aexit__(self, *args): ...

# error: [invalid-context-manager] "Object of type `Manager` cannot be used with `with` because it does not implement `__enter__` and `__exit__`"
with Manager():
    ...

The error naturally happens since __enter__ and __exit__ are not implemented but we observe that __aenter__ and __aexit__ are implemented. Using this information, the heuristic is that the user probably wanted to use async with which is now mentioned in the subdiagnostics as :

note: Objects of type `Manager` *can* be used as async context managers
note: Consider using `async with` here

Test Plan

I have create a mdtest with snapshot to capture the additional subdiagnostics. I can create more tests if needed.

[github-actions]

mypy_primer results

No ecosystem changes detected ✅

[lipefree]

When looking at the mdtest itself, it is hard to know that what is expected, is the additional information provided in the sub-diagnosis. I don't know if I can improve it so that it is clear how the sub-diagnosis should look like instead of having to look at the snap file.

[sharkdp]

These __aenter__ and __aexit__ calls will fail if you modify/extend your test example and annotated the parameter types of these two methods on the Manager class accordingly. None will not generally be a valid type for all of the arguments.

We do not necessarily need to be very strict with the passed argument types here (since we're only using it to add a diagnostic hint, and it seems fine to emit it even if that call would fail when passing the wrong parameters). So I guess it's fine to pass Type::unknown() here instead? Another option would be to allow not just Ok(_) results, but also Err(CallDunderError::CallError(..))?

[lipefree]

Hey ! Thank you for the review ! If I understand correctly you want to add the sub-diagnosis event if the code was not annotating the types correctly ?
Example :

class Foo:
    async def __aenter__(self):
        ...
    
    def __aexit__(self,
                 exc_type: str, # <= wrong type
                 exc_value: str,
                 traceback: str
                ):
        ...
        
with Foo():
    ...

But even in this case, we should provide the sub-diagnosis even if the provided typing is incorrect. I guess it makes sense. I am just too unexperienced yet, should I implement it to take care of this case ? But then should we also provide the sub-diagnosis if the user is passing the wrong number of arguments ?

class Foo:
    async def __aenter__(self):
        ...
    
    def __aexit__(self,
                 exc_type,
                 exc_value,
                 traceback,
                 extra_arg
                ):
        ...
        
with Foo():
    ...

[sharkdp]

But then should we also provide the sub-diagnosis if the user is passing the wrong number of arguments ?

Probably? I think you could achieve this by following this route:

Another option would be to allow not just Ok(_) results, but also Err(CallDunderError::CallError(..))?

I think we should pass Type::unknown() anyway. Passing None is just wrong.

[lipefree]

I will address this and add more testing then !

[sharkdp]

Just to clarify, in case it was unintentional: you're still using Type::none in your latest commit, instead of Type::unknown.

[lipefree]

Sorry I just changed it in the last commit. Thank you very much for bearing with me !

[sharkdp]

Thank you!

I pushed one commit with a code simplification and some minor rewordings.

[sharkdp]

This can be simplified to

Suggested change

	if let (Ok(_) | Err(CallDunderError::CallError(..)), Ok(_))
	| (Ok(_), Err(CallDunderError::CallError(..))) = (
	if let (
	Ok(_) | Err(CallDunderError::CallError(..)),
	Ok(_) | Err(CallDunderError::CallError(..)),
	) = (

I think.

[lipefree]

Thank you very much for all the reviews you gave, I really learned a lot during this PR about python, rust and ty !