[asukaminato0721]

Summary

Fixes #2752

applying class decorators to the runtime class-value bindingm while preserving the original class object when a decorator still returns a usable type form.

Test Plan

add test

[Copilot]

Pull request overview

This PR enhances Pyrefly’s solver to type-check class decorator application so the decorated class name can be rebound to the decorator’s return type (e.g., @remote turning a class name into an ActorHandle[...]), and adds a regression test covering this behavior.

Changes:

• Apply non-dataclass-transform class decorators during Binding::ClassDef type solving to infer the post-decoration value type.
• Extend untype_opt/expr_untype handling for Type::KwCall and name lookups to better support the new decorator behavior.
• Add a new decorator test case ensuring a class decorator can rebind the class value.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
pyrefly/lib/test/decorators.rs	Adds a regression testcase for a class decorator that rebinds the class symbol to an ActorHandle[T].
pyrefly/lib/alt/solve.rs	Implements class-decorator application during solving and adjusts untyping/name handling to support the new behavior.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review. Take the survey.

[yangdanny97]

Overall: This is a clear regression. The PR's class decorator support mishandles decorators whose return types are Unknown/unresolvable, causing 179 false positive errors across the spack project. The decorator @lang.lazy_lexicographic_ordering returns the class itself at runtime, but pyrefly now types the class as ((realf: Unknown) -> Unknown) | Unknown, cascading into missing-attribute, not-a-type, invalid-inheritance, unexpected-keyword, and other errors. None of these are flagged by mypy or pyright.

@migeed-z why does this get classified as "improvement" lol

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

[meta-codesync]

This pull request has been imported. If you are a Meta employee, you can view this in D115174934. (Because this pull request was imported automatically, there will not be any future comments.)

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

[codspeed]

Merging this PR will not alter performance

✅ 35 untouched benchmarks
⏩ 9 skipped benchmarks¹

---

_{Comparing asukaminato0721:2752 (6e46feb) with main (9465298)}

Footnotes

1. 9 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

[stroxler]

Note: #2294 generally supersedes this, this is a much more restrictive subset of the bigger change where we fully interpret class decorators.

At the moment I think we should take #2294 instead, but there are questions, particularly around backward compatibility. If we take #2294 but make the existing mypy-like behavior our default, then it is likely we might want to merge this change

[stroxler]

Closing this in favor of #2294, which we want to get over the line

[github-actions]

Closing this PR because linked issue #2752 was closed.