Our current logic is as follows:
Whenever a user changes a file, we trigger a compilation:
Step 1 is converting the root_uri to a root_path
Step 2, resolve any user-configured reference directories (relative to root_path)
Step 3, construct a new SliceOptions with those references
Step 4, perform the compilation
Step 5, store the SliceOptions we just created and the CompilationState(Result) returned by slicec in SharedState.
This PR makes the following improvements:
Step 1 only needs to happen once. We only set the root_uri at initialization, and the only thing we do with it is convert it into a root_path. Now, we do this conversion once, on server start-up, and store the root_path instead of root_uri.
Steps 2 and 3 only need to happen when configuration changes, not every time we re-compile.
Now, whenever the config changes, we update the references and cache them up-front.
We're double-storing the references. Once in SliceConfig, and once in SliceOptions. These are redundant.
Now we store the SliceOptions directly in SliceConfig. Since the SliceOptions only depends on the config. Nothing else.
After this change, SharedState only holds a CompilationState. So there's no reason to have SharedState anymore. We just hold the CompilationState directly.
Our current logic is as follows: Whenever a user changes a file, we trigger a compilation:
root_urito aroot_pathroot_path)SharedState.This PR makes the following improvements:
root_uriat initialization, and the only thing we do with it is convert it into aroot_path. Now, we do this conversion once, on server start-up, and store theroot_pathinstead ofroot_uri.SliceConfig, and once inSliceOptions. These are redundant. Now we store theSliceOptionsdirectly inSliceConfig. Since the SliceOptions only depends on the config. Nothing else.SharedStateonly holds aCompilationState. So there's no reason to haveSharedStateanymore. We just hold theCompilationStatedirectly.