-
Notifications
You must be signed in to change notification settings - Fork 437
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add synthetic triggered dependencies for FunctionDefinitions
Summary: I've been debugging a Pyre incremental problem for the past day, which I can repro at-large (i.e. it's repeatable) but so far I can't actually get a small repro which makes it difficult to pin down. The issue we were seeing is that after applying a `pyre-upgrade` to a big codebase, there were many files where we would have both an unused ignore *and* the original error reported! I eventually realized the line numbers were mismatched; the actual type errors had incorrect locations, whereas the unused ignores matched the updated source file. This indicates that TypeEnvironment had errors from the old code, and then ErrorsEnvironment / Postprocessing was applying suppressions using the current raw source against these out-of-date type errors. --------------- I still do not know *exactly* why this happens at the level of detail I would like to; after skimming the code, it appears to me that we should be getting triggered dependencies for `FunctionDefinitionEnvironment` reads, which means any previously-checked module ought to be re-checked after the raw source changes. But I did notice two things: - there was exactly one place where UnannotatedGlobalEnvironment is treated differently than FunctionDefinitionEnvironment, which is that AstEnvironment *forces* triggered dependencies for all invalidated modules. - while I still can't figure out why this would be necessary for pre-existing sources (I need to debug more, but I also need to ship a fix), I have confirmed that with this diff the bug disappears. - In addition, I actually *can* see why this change is needed when *new* sources pop up: if we don't force a "fake" triggered dependency, we wind up not type checking new source files. I'm going ahead and putting this up for review because even if I don't fully understand the bug yet, I know that (a) this change fixes the problem, and (b) this change is necessary in any case because of the new-source-file issue. ------------------ I filed T196249034 to keep investigating. I think it's pretty important to determine why dependency tracked table reads aren't sufficient to prevent this kind of problem, but it may take some time because so far I've failed to make a trivial repro. Once I figure out the root cause, I should either simplify (if possible) or clearly document exactly what the control flow is that makes this hook necessary. Reviewed By: grievejia Differential Revision: D59993520 fbshipit-source-id: 5beac07fd3b700b3ef90492094e7cf205b393ebc
- Loading branch information
1 parent
0b4079a
commit aa73d70
Showing
3 changed files
with
65 additions
and
44 deletions.
There are no files selected for viewing
This file contains 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
This file contains 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
This file contains 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