It appears that the generic signature builder resolves types twice because the availability of the generic environment can influence diagnostics (see revertGenericFuncSignature() and its uses). This seems unfortunate and inefficient. Should AST node validation be tri-state? For example, default to "unknown", and allow one-way transitions to either "valid" or "invalid". Finally, assert in the AST verifier that all nodes are either valid or invalid. What do people think about this added level of discipline? Being "known valid" would let us bypass the redundant type resolving.
The need to have ârevertGenericFuncSignatureâ is really unfortunate. The problem stems from the fact that we record not-completely-type-checked types in the AST, then have to undo that to put the correct types in place. It can cause problems particularly when there are cyclic dependencies almost declarations.
I donât think the right answer is to make the âvalidatedâ state tri-state, though. Instead, we should port this code path over to the request-evaluator, which has different queries depending on the level of information thatâs required: âstructuralâ type information thatâs only about the shape of the types but is otherwise unchecked, âinterfaceâ type information thatâs a fully-checked interface type, or âcontextualâ type information that describes the archetypes. The request-evaluator can keep these pieces of information separate, so thereâs no need to ârevertâ.
Interesting. Good to know. What then is the preferred way to avoid redundant diagnostics in this scenario? Right now, my "resolveType()" changes assume that the code will be reinvoked if a GenericTypeParamType is involved AND the generic environment is null. Is this okay, or is there a better way?