[ty] Don't add incorrect subdiagnostic for unresolved reference

[MatthewMckee4]

Summary

Don't add subdiagnostic in staticmethod, and change message for classmethod

Resolves astral-sh/ty#584 (partially i think)

Test Plan

Add test and update snapshot

[github-actions]

mypy_primer results

No ecosystem changes detected ✅

[carljm]

Thank you!

[MatthewMckee4]

I've cleaned this up a bit, but i'm getting panics because of the decorator expression inference. Im not sure what order and function i should call to infer the type of the decorator expression.

[carljm]

A core invariant of our type inference is that each AST node gets a type inferred for it once, in the "inference region" responsible for that node (an inference region can be a scope, a definition, or a standalone expression), and then that type gets merged into the surrounding region as needed, but doesn't get re-inferred willy-nilly.

So I don't think it will work well to have the function_decorators method just take a list of AST nodes; this means we'll end up re-inferring its type ad-hoc from various call-sites, and that won't work well.

The function decorators should have their type inferred exactly once, in infer_function_definition (via infer_decorator). We shouldn't call self.infer_expression or similar on those same nodes anywhere else.

The previous code here that checked for abstract methods and overloads used self.file_expression_type on those decorator nodes, which doesn't re-infer them: it looks up what scope they belong to, infers that entire scope, and then pulls the expression types out. This worked, but isn't really ideal because it infers far more than necessary. A function definition is always a definition, and the decorator nodes are part of that definition, so we don't need to infer the entire scope, just the definition.

So the ideal here would be to find the Definition for the function (scopes know the Definition that creates them, so this shouldn't be hard to get from the body scope) and then use definition_expression_type to infer types for that definition and pull the specific inferred expression types out. (Although it seems like we store on the OverloadLiteral for the function what known decorators it has, so if we get the type for the function definition we can maybe just use that and not need to pull out specific decorator expressions at all?

[MatthewMckee4]

i've not yet used definition_expression_type, but there's also tests failing and i can't see what regression ive made

[codspeed-hq]

CodSpeed Instrumentation Performance Report

Merging #18487 will not alter performance

_{Comparing MatthewMckee4:incorrect-subdiagnostic-for-unresolved-reference (ba648f9) with main (57bd7d0)}

Summary

✅ 39 untouched benchmarks

[AlexWaygood]

There's a surprisingly large mypy_primer diff on this PR right now

[carljm]

Yeah, the mypy primer diff definitely seems to indicate something unexpected is happening here. Don't have time to investigate it further right now, will have to come back to this later.

[sharkdp]

Moving this to draft for now, feel free to move it back to review whenever you think it's ready for another round of review.

[AlexWaygood]

Thanks, this is great. It looks like the primer hits have all gone now that #18809 has landed on main, so I think this is good to go now!

requested changes were made