You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Stabilize the build system by correctly house keeping the dirtykeys and rule values [flaky test #4185#4093] (#4190)
The main problem is the out of sync state in the build system. Several states involved, the shake database running result state for key. shake extra's dirty state for key and shake extra's rule values state.
To stablize the build system. This PR force some of the updates of these state into a single STM block.
1. collect dirtykeys and ship it to session restart directly. No more invalid removal before session restart. Fixing Flaky test failure result in error of GetLinkable #4093
2. move the dirtykey removal and rules values updating to hls-graph by adding a call back fucntion to RunResult. Properly handle the dirtykeys and rule value state after session start and closely followed by another session restart Fixing ghcide-tests' addDependentFile test #4194
3. properly handle clean up by wrapping the asyncWithCleanUp to refreshDeps
---------
Co-authored-by: wz1000 <[email protected]>
Co-authored-by: Jan Hrcek <[email protected]>
Co-authored-by: Michael Peyton Jones <[email protected]>
-- Note [Housekeeping rule cache and dirty key outside of hls-graph]
1260
+
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1261
+
-- Hls-graph contains its own internal running state for each key in the shakeDatabase.
1262
+
-- ShakeExtras contains `state` field (rule result cache) and `dirtyKeys` (keys that became
1263
+
-- dirty in between build sessions) that is not visible to the hls-graph
1264
+
-- Essentially, we need to keep the rule cache and dirty key and hls-graph's internal state
1265
+
-- in sync.
1266
+
1267
+
-- 1. A dirty key collected in a session should not be removed from dirty keys in the same session.
1268
+
-- Since if we clean out the dirty key in the same session,
1269
+
-- 1.1. we will lose the chance to dirty its reverse dependencies. Since it only happens during session restart.
1270
+
-- 1.2. a key might be marked as dirty in ShakeExtras while it's being recomputed by hls-graph which could lead to it's premature removal from dirtyKeys.
1271
+
-- See issue https://github.com/haskell/haskell-language-server/issues/4093 for more details.
1272
+
1273
+
-- 2. When a key is marked clean in the hls-graph's internal running
1274
+
-- state, the rule cache and dirty keys are updated in the same transaction.
1275
+
-- otherwise, some situations like the following can happen:
1276
+
-- thread 1: hls-graph session run a key
1277
+
-- thread 1: defineEarlyCutoff' run the action for the key
1278
+
-- thread 1: the action is done, rule cache and dirty key are updated
1279
+
-- thread 2: we restart the hls-graph session, thread 1 is killed, the
1280
+
-- hls-graph's internal state is not updated.
1281
+
-- This is problematic with early cut off because we are having a new rule cache matching the
1282
+
-- old hls-graph's internal state, which might case it's reverse dependency to skip the recomputation.
1283
+
-- See https://github.com/haskell/haskell-language-server/issues/4194 for more details.
0 commit comments