We have been having a number of issues with race conditions in tests where the shared list of builtins was required to be in a different state in different tests. Namely, the single file language server test that updated the config to use a different caps list, and inlay hints which was also based on this data.
After some consideration, it appears to make sense that the built ins, being related to the loaded caps, should be provided when required, rather than being fetched from the global state. This means that the code requiring builtins can continue to operate while needing know knowledge of what the builtins list should be, as that is now a concern of the caller.
I have added field on the server to store the state of builtins for different caps versions which we can use to pass down a list of builtins from when needed in the various server functions.
Built ins must now be provided by the caller.
We have been having a number of issues with race conditions in tests where the shared list of builtins was required to be in a different state in different tests. Namely, the single file language server test that updated the config to use a different caps list, and inlay hints which was also based on this data.
After some consideration, it appears to make sense that the built ins, being related to the loaded caps, should be provided when required, rather than being fetched from the global state. This means that the code requiring builtins can continue to operate while needing know knowledge of what the builtins list should be, as that is now a concern of the caller.
I have added field on the server to store the state of builtins for different caps versions which we can use to pass down a list of builtins from when needed in the various server functions.
Related https://github.com/StyraInc/regal/pull/1101 https://github.com/StyraInc/regal/pull/1102 https://github.com/StyraInc/regal/pull/1112 https://github.com/StyraInc/regal/pull/1121 https://github.com/StyraInc/regal/pull/1129