Report errors correctly by invalidating super set of affected files#25534
Closed
sheetalkamat wants to merge 1 commit into
Closed
Report errors correctly by invalidating super set of affected files#25534sheetalkamat wants to merge 1 commit into
sheetalkamat wants to merge 1 commit into
Conversation
82529f7 to
edd0007
Compare
Contributor
|
Do we need to do anything here? is there a better way to detect cases where these transitive dependencies lead to invalidation? seems like most of the time transitive dependencies do not introduce errors. seems like this is a drastic change.. |
Member
Author
|
Closing in favor of #25593 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #24986
The issue reported was with the graph a -> b -> c
When change was made c, the declaration file for b doesnt change (it still remains
import {C}from "./c" export class B{ c: C}). From emit persepctive file a.ts doesnt need to be emitted (since its not part of affected files by that change) and without deleting errors for a.ts we wont see new error.With this change, whenever change in declaration file for c happens, we not only delete errors for b.ts, we will delete errors for a.ts (since it references b.ts) and any file that will reference a.ts as well. This will hamper the performance in scenarios where errors didnt change (eg if a.ts never referenced b.c.d property) but finding out such dependencies would be costlier than re-generating errors.