TS7022 (circular reference) on simple assignments in a loop about typescript HOT 6 CLOSED

Please see #33191 and #42529. The behavior change in 5.4 is likely attributed to #56753. It is indeed somewhat interesting that the tooltip does show a type other than any.

from typescript.

I'm fixing the weird inconsistent quick info display here: #59075

from typescript.

Please see #33191 and #42529. The behavior change in 5.4 is likely attributed to #56753. It is indeed somewhat interesting that the tooltip does show a type other than any.

Those issues look similar but I'm not sure the root cause is the same. The supposed circularity in my repro code is being caused by an empty if statement which is essentially dead code here. I assume it's narrowing something internally but given that it's not affecting the control flow at all (can be removed with zero consequences to the runtime), I don't see a good reason for this narrowing to be occurring. (Well, in the code that sparked the issue the if statement is not exactly dead code, but it's still unrelated to the variable that's getting the error.)

I'm fixing the weird inconsistent quick info display here: #59075

Doesn't that make it worse, though? The problem is in the extraneous error here, the tooltip has the correct type...

from typescript.

The supposed circularity in my repro code is being caused by an empty if statement which is essentially dead code here

It requests type of test which in turn depends on the type of alsoChat. That's how the circularity happens here. I agree that it's weird that some very similar cases work without running into circularity.

Doesn't that make it worse, though? The problem is in the extraneous error here, the tooltip has the correct type...

The tooltip has the correct type somewhat accidentally here. CheckMode.TypeOnly was introduced to suppress comparability errors when dealing with intermediate types created during control flow analysis. Those errors that were suppressed by that PR didn't affect the control flow analysis at all. So it was OK to suppress them.

An encountered circularity returns any type and that very much can propagate through the types computed during control flow analysis. That's why I think it wouldn't be good to suppress this error here in a similar way.

That said, this alternative patch doesn't change anything in the existing test suite and it "fixes" your particular circularity issue:

diff --git a/src/compiler/checker.ts b/src/compiler/checker.ts
index a965c51d22..640a0216c5 100644
--- a/src/compiler/checker.ts
+++ b/src/compiler/checker.ts
@@ -12055,6 +12055,9 @@ export function createTypeChecker(host: TypeCheckerHost): TypeChecker {
             if (isBindingElement(declaration) && checkMode === CheckMode.Contextual) {
                 return errorType;
             }
+            if (checkMode && checkMode & CheckMode.TypeOnly) {
+                return anyType;
+            }
             return reportCircularityError(symbol);
         }
         let type: Type;
@@ -12137,6 +12140,9 @@ export function createTypeChecker(host: TypeCheckerHost): TypeChecker {
             if (isBindingElement(declaration) && checkMode === CheckMode.Contextual) {
                 return type;
             }
+            if (checkMode && checkMode & CheckMode.TypeOnly) {
+                return anyType;
+            }
             return reportCircularityError(symbol);
         }
         return type;

But despite that, I think it's rather risky to allow this to propagate freely because the result propagates. Similarly, getTypeOfExpression sets NodeFlags.TypeCached on the node but in this scenario the type wouldn't actually be cached! That's just a different bug waiting to happen somewhere.

I also checked that it wouldn't have a perceivable bad impact on this scenario with an auto type:

declare const line: string;
let test;

for (let i = 0; i < line.length; i++) {
  const char = line[i];
  if (test === char) {}
  const alsoChar = char;
  test = alsoChar;
}

FWIW, I'm not saying that the circularity avoidance couldn't be improved for some of those cases. I feel like the change I proposed is good regardless of that.

from typescript.

#56753 is being superceded by #59183. This is a true circularity for basically the same reason as #33191 (comment).

See also https://github.com/Microsoft/TypeScript/wiki/FAQ#circularity-errors-may-occur-in-the-presence-of-circularities

from typescript.

This issue has been marked as "Not a Defect" and has seen no recent activity. It has been automatically closed for house-keeping purposes.

from typescript.