* [bench-hist] break down in rule functions
* Extract the benchmarking Shake rules to a shake-bench package
There's some room for reusing the rules used in the historic benchmarking suite
in other projects. This change makes that a bit easier and improves the
documentation and code structure.
The new structure is:
- lib:shake-bench - a Cabal library with functions to generate Shake rules
- ghcide:bench:benchHist - the ghcide instantiation of the above Shake rules
That's not to say that shake-bench is completely decoupled from ghcide -
there are still plenty of assumptions on how the benchmarks are organized, their
outputs, etc. But with a little bit of effort, it should be easy to make
these rules more reusable
* Fix nix build
* Fix license
* hlints and redundant imports
* more hlints
* Exclude shake-bench from the stack build
* Enable tests in windows ci
* Use lsp-test-0.11.0.6
* Fix tests in windows
* Use chocolatey to install cabal in ci
* Fix test: type constructor external
* Fix test: non workspace file
* Mark cpp-error as ignored for windows
* Ignore plugin tests for windows
* Store client settings in ide state
* Log ide config registered in initHandler
* Use a Maybe aware updater function
* Create a Rule to get client settings
* Create a specific getter for client settings
* Trim trailing whitespace
* Use modifyVar to avoid race conditions
* Add comment to GetClientSettings
* Use defineEarlyCutOffNoFile for GetClientSettings
* Restart shake on config changed
* Use Hashed for clientSettings
* Send log notifications to client about session
* Show test output directly
* Add tests over client settings
* Apply hlint hints
* Simplify iface test to make it more robust
Following @pepeiborra advise
* Send session notifications only in test mode
* Retry bench execution
* Use implicit-hie when no explicit hie.yaml
* Use implicit-hie-cradle master in all build config files
* Set correct hie-bios version for ghc-8.10.1
* Fix windows ci build
* Use stale information for hover and completions
This introduces a new function `useWithStaleFast` which returns with
stale information WITHOUT checking freshness like `use` and
`useWithStale`.
Greatly improve debug logging
All actions triggered by shakeRun now also pass an identifier which
means that the debug logging shows which actions are starting/finishing
We also distinguish between internal and external events. By default
external events are ones triggered by runAction and the debug output
is displayed to the user in command line and --lsp mode.
In order to see internal logging statements, there is a new flag called
--verbose which also prints out internal events such as file
modification flushes.
Cleaner variant using runAfter
Step 1: Do not run actions with shakeRun
Queue implementation, living, breathing
Use a priority queue to schedule shake actions.
Most user actions are answered immediately with a cache but also
spawn a shake action to check the cached value we consulted was up to
date.
* Remove DelayedActionExtra
* hlint
* Fix progress
* Always block instead of fail on initial computation
* Can block for code lens
* Update docs
Co-authored-by: Zubin Duggal <zubin@cmi.ac.in>
