-
Notifications
You must be signed in to change notification settings - Fork 649
Report iteration errors on all error nodes #1061
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
8272017
c9f7b9e
a5a4449
4bb5800
1dfc0da
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -470,7 +470,6 @@ const ( | |
IterationUseSpreadFlag IterationUse = 1 << 5 | ||
IterationUseDestructuringFlag IterationUse = 1 << 6 | ||
IterationUsePossiblyOutOfBounds IterationUse = 1 << 7 | ||
IterationUseReportError IterationUse = 1 << 8 | ||
// Spread, Destructuring, Array element assignment | ||
IterationUseElement = IterationUseAllowsSyncIterablesFlag | ||
IterationUseSpread = IterationUseAllowsSyncIterablesFlag | IterationUseSpreadFlag | ||
|
@@ -481,7 +480,7 @@ const ( | |
IterationUseAsyncYieldStar = IterationUseAllowsSyncIterablesFlag | IterationUseAllowsAsyncIterablesFlag | IterationUseYieldStarFlag | ||
IterationUseGeneratorReturnType = IterationUseAllowsSyncIterablesFlag | ||
IterationUseAsyncGeneratorReturnType = IterationUseAllowsAsyncIterablesFlag | ||
IterationUseCacheFlags = IterationUseAllowsSyncIterablesFlag | IterationUseAllowsAsyncIterablesFlag | IterationUseForOfFlag | IterationUseReportError | ||
IterationUseCacheFlags = IterationUseAllowsSyncIterablesFlag | IterationUseAllowsAsyncIterablesFlag | IterationUseForOfFlag | ||
) | ||
|
||
type IterationTypes struct { | ||
|
@@ -5882,18 +5881,26 @@ func (c *Checker) getIterationTypesOfIterable(t *Type, use IterationUse, errorNo | |
if IsTypeAny(t) { | ||
return IterationTypes{c.anyType, c.anyType, c.anyType} | ||
} | ||
key := IterationTypesKey{typeId: t.id, use: use&IterationUseCacheFlags | core.IfElse(errorNode != nil, IterationUseReportError, 0)} | ||
key := IterationTypesKey{typeId: t.id, use: use&IterationUseCacheFlags} | ||
// If we are reporting errors and encounter a cached `noIterationTypes`, we should ignore the cached value and continue as if nothing was cached. | ||
// In addition, we should not cache any new results for this call. | ||
noCache := false | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. alternatively, I could use There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I have a feeling that we might want to do that, just because we can hit this path through regular checker methods externally and then repeatedly tack more diagnostics onto the list. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. done There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Actually, won't this be like one entry for every single loop, yield, etc, that we check? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Both options seem bad, kinda... There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hm, I guess the way you had it originally was more similar to the original code, right? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yes, it was more similar - and it only was re-retrieving the iteration types when the cached value had no types. So it seems it should be faster than including the nodeId in the cache key There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Okay, then I guess go back, sorry 😄 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I pushed out a revert going back to the |
||
if cached, ok := c.iterationTypesCache[key]; ok { | ||
return cached | ||
if errorNode == nil || cached.hasTypes() { | ||
return cached | ||
} | ||
noCache = true | ||
} | ||
result := c.getIterationTypesOfIterableWorker(t, use, errorNode, noCache) | ||
if !noCache { | ||
c.iterationTypesCache[key] = result | ||
} | ||
result := c.getIterationTypesOfIterableWorker(t, use, errorNode) | ||
c.iterationTypesCache[key] = result | ||
return result | ||
} | ||
|
||
func (c *Checker) getIterationTypesOfIterableWorker(t *Type, use IterationUse, errorNode *ast.Node) IterationTypes { | ||
func (c *Checker) getIterationTypesOfIterableWorker(t *Type, use IterationUse, errorNode *ast.Node, noCache bool) IterationTypes { | ||
if t.flags&TypeFlagsUnion != 0 { | ||
return c.combineIterationTypes(core.Map(t.Types(), func(t *Type) IterationTypes { return c.getIterationTypesOfIterableWorker(t, use, errorNode) })) | ||
return c.combineIterationTypes(core.Map(t.Types(), func(t *Type) IterationTypes { return c.getIterationTypesOfIterableWorker(t, use, errorNode, noCache) })) | ||
jakebailey marked this conversation as resolved.
Show resolved
Hide resolved
|
||
} | ||
if use&IterationUseAllowsAsyncIterablesFlag != 0 { | ||
iterationTypes := c.getIterationTypesOfIterableFast(t, c.asyncIterationTypesResolver) | ||
|
This file was deleted.
This file was deleted.
This file was deleted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
was this even concurrent-checking safe? wouldn't we, potentially, get a different set of errors with multiple error nodes given each concurrent checker could report the error for a different firt encountered
errorNode
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, yes, I agree, though I believe it's handled because we spawn a specific number of checkers and then round robin them, and then they all walk their files in order, so it's always consistent.
But, I think we should probably change it, since this affects the editor and would change if we allow custom checker counts.