| commit | b7ccef0e2c95ae3a2410f092a14c89e94840bc1f | |
| author | Lucian Wischik <ljw@fb.com> | |
| Mon, 9 Oct 2017 18:46:33 +0000 (9 11:46 -0700) | ||
| committer | Hhvm Bot <hhvm-bot@users.noreply.github.com> | |
| Mon, 9 Oct 2017 19:04:08 +0000 (9 12:04 -0700) | ||
| tree | a9b781927449dd6cd0dd325d4c9687e35e4d32af | treesnapshot (tar.gz zip) |
| parent | 1751f97e5f03b229bfd6c19cbbaf8ef5e9074423 | commitdiff |
dismiss diagnostics if hh_server goes down
Summary:
When hh_server goes down, we should flush all diagnostics that we've reported so far. (If hh_server comes back again, then we can restore them).
Reason: imagine if we were in a state with errors shown in Nuclide, and then did a rebase (say) or some other operation that killed hack and later we fixed the errors while Hack was busy restarting. The new Hack instance would have no way of knowing which errors were already shown in Nuclide, and so would have no way of dismissing them. The only solution is to dismiss them as soon as hh_server goes down.
Reviewed By: arxanas
Differential Revision: D6004209
fbshipit-source-id: 6465ac62be2310aee8f3096355d93593ca807d86
Summary:
When hh_server goes down, we should flush all diagnostics that we've reported so far. (If hh_server comes back again, then we can restore them).
Reason: imagine if we were in a state with errors shown in Nuclide, and then did a rebase (say) or some other operation that killed hack and later we fixed the errors while Hack was busy restarting. The new Hack instance would have no way of knowing which errors were already shown in Nuclide, and so would have no way of dismissing them. The only solution is to dismiss them as soon as hh_server goes down.
Reviewed By: arxanas
Differential Revision: D6004209
fbshipit-source-id: 6465ac62be2310aee8f3096355d93593ca807d86
| hphp/hack/src/client/clientLsp.ml | diffblobblamehistory |