[red-knot] Use try_call_dunder infrastructure consistently

[sharkdp]

Summary

__enter__ and __exit__ should be treated like all other dunder methods. However, while working on #16368, I noticed that we look them up manually (and potentially incorrectly) here …

ruff/crates/red_knot_python_semantic/src/types/infer.rs

Lines 1621 to 1622 in 1be0dc6

	let enter = context_manager_ty.member(self.db(), "__enter__");
	let exit = context_manager_ty.member(self.db(), "__exit__");

… and call them manually (and potentially incorrectly) here:

ruff/crates/red_knot_python_semantic/src/types/infer.rs

Lines 1660 to 1661 in 1be0dc6

	let target_ty = enter_ty
	.try_call(self.db(), &CallArguments::positional([context_expression_ty]))

This only leads to incorrect behavior in very exotic situations like the following, where we incorrectly raise a "Object of type Manager cannot be used with with because it does not correctly implement __enter__" diagnostic:

from __future__ import annotations

class Target: ...

class SomeCallable:
    def __call__(self) -> Target:
        return Target()

class Descriptor:
    def __get__(self, instance, owner) -> SomeCallable:
        return SomeCallable()

class Manager:
    __enter__: Descriptor = Descriptor()

    def __exit__(self, exc_type, exc_value, traceback): ...

with Manager() as f:
    reveal_type(f)  # revealed: Target

Fixing this would involve using try_call_dunder after #16368 is merged, or using static_member + a manual descriptor call, if that is not possible.

[sharkdp]

The same is probably true for __class_getitem__:

ruff/crates/red_knot_python_semantic/src/types/infer.rs

Lines 5220 to 5221 in 1be0dc6

	let dunder_class_getitem_method =
	value_ty.member(self.db(), "__class_getitem__");

ruff/crates/red_knot_python_semantic/src/types/infer.rs

Line 5238 in 1be0dc6

.try_call(self.db(), &CallArguments::positional([value_ty, slice_ty]))

[sharkdp]

And augmented assignments:

ruff/crates/red_knot_python_semantic/src/types/infer.rs

Lines 2259 to 2267 in 1be0dc6

	Type::Instance(instance) => {
	if let Symbol::Type(class_member, boundness) = instance
	.class()
	.class_member(self.db(), op.in_place_dunder())
	{
	let call = class_member.try_call(
	self.db(),
	&CallArguments::positional([target_type, value_type]),
	);

[sharkdp]

And in/not in tests:

ruff/crates/red_knot_python_semantic/src/types/infer.rs

Lines 4902 to 4910 in 1be0dc6

	let contains_dunder = right.class().class_member(db, "__contains__");
	let compare_result_opt = match contains_dunder {
	Symbol::Type(contains_dunder, Boundness::Bound) => {
	// If `__contains__` is available, it is used directly for the membership test.
	contains_dunder
	.try_call(
	db,
	&CallArguments::positional([Type::Instance(right), Type::Instance(left)]),
	)

[sharkdp]

… and subscript expressions (this is the last one, I promise):

ruff/crates/red_knot_python_semantic/src/types/infer.rs

Lines 5220 to 5238 in 1be0dc6

	let dunder_class_getitem_method =
	value_ty.member(self.db(), "__class_getitem__");
	match dunder_class_getitem_method {
	Symbol::Unbound => {}
	Symbol::Type(ty, boundness) => {
	if boundness == Boundness::PossiblyUnbound {
	self.context.report_lint(
	&CALL_POSSIBLY_UNBOUND_METHOD,
	value_node,
	format_args!(
	"Method `__class_getitem__` of type `{}` is possibly unbound",
	value_ty.display(self.db()),
	),
	);
	}
	return ty
	.try_call(self.db(), &CallArguments::positional([value_ty, slice_ty]))