mirror of https://github.com/astral-sh/ruff
As described in astral-sh/ty#1729, we previously had a salsa cycle when inferring the signature of many function definitions. The most obvious case happened when (a) the function was decorated, (b) it had no PEP-695 type params, and (c) annotations were not always deferred (e.g. in a stub file). We currently evaluate and apply function decorators eagerly, as part of `infer_function_definition`. Applying a decorator requires knowing the signature of the function being decorated. There were two places where signature construction called `infer_definition_types` cyclically. The simpler case was that we were looking up the generic context and decorator list of the function to determine whether it has an implicit `self` parameter. Before, we used `infer_definition_types` to determine that information. But since we're in the middle of signature construction for the function, we can just thread the information through directly. The harder case is that signature construction requires knowing the inferred parameter and return type annotations. When (b) and (c) hold, those type annotations are inferred in `infer_function_definition`! (In theory, we've already finished that by the time we start applying decorators, but signature construction doesn't know that.) If annotations are deferred, the params/return annotations are inferred in `infer_deferred_types`; if there are PEP-695 type params, they're inferred in `infer_function_type_params`. Both of those are different salsa queries, and don't induce this cycle. So the quick fix here is to always defer inference of the function params/return, so that they are always inferred under a different salsa query. A more principled fix would be to apply decorators lazily, just like we construct signatures lazily. But that is a more invasive fix. Fixes astral-sh/ty#1729 --------- Co-authored-by: Alex Waygood <alex.waygood@gmail.com> |
||
|---|---|---|
| .. | ||
| corpus | ||
| mdtest | ||
| primer | ||
| README.md | ||
README.md
Markdown files within the mdtest/ subdirectory are tests of type inference and type checking;
executed by the tests/mdtest.rs integration test.
See crates/ty_test/README.md for documentation of this test format.