Sync with upstream #2
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Fourmolu 0.7 (due to Ormolu 0.5) removes the `--cabal-default-extensions` flag, instead looking for Cabal files by default. If input is taken from stdin and `--stdin-input-file` isn't specified, it therefore fails. We don't need to make any changes in non-CLI mode because the Cabal file handling logic occurs at a higher level outside the entry point we use to the library (the `ormolu` function).
Allows us to use Fourmolu 0.7.
Fix Fourmolu 0.7 support
* Support ghc-9.2.3 * ormolu-0.5 * Update stack.yaml Co-authored-by: Pepe Iborra <[email protected]>
* Use proper structured logging for Fourmolu Previously we just printed directly to stdout and stderr. * Don't run Fourmolu in debug mode It prints to stderr, due to uses of `traceM`, and it's not nice to work around this downstream. It's of questionable utility anyway. The fact that it mostly prints information about extensions, and does so in a hard-to-read format (a string displayed as a list!) indicates that it probably isn't widely used. * Fourmolu: parse strings to integers before comparing versions Whoever originally wrote this (😳) had clearly had one too many beers the night before: `show @Int` is not monotonic since e.g. "10" < "2".
Add a `.hi.core` file format to which we serialize out compiled core after generating it. This core is then read back in on subsequent runs and compiled to bytecode. This greatly speeds up startup times when we need compilation, as we can simply read bytecode off the disk instead of having to recompile a lot of modules This is based off Fat Interface files in GHC: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7502 - Also add --verify-core-file to do roundtrip testing of core-files - Use closed world assumption for core and .hie files
Adds a new rule `GetLinkable` which is called on demand by hscCompileCoreExprHook whenever a linkable is required for a splice. Adds a MonadUnliftIO instance for Action to faciliate the above We write Core Files whenever a linkable could potentially be required for a file (i.e it is in the transitive closure of a module that uses TH/compile time code execution) However, we only generate byte/object code when such a linkable is really required by a splice (i.e. the module is in the transitive closure of any symbol called from a splice). No linkables are stored in `HiFileResult`. If a linkable is required, then it must be obtained via a call to `GetLinkable`. Also use hashes to do fine grained recompilation checking for TH instead of mod times. This simplifies recompilation checking quite a bit.
…askell#2956) * hls-class-plugin: Only create placeholders for unimplemented methods * hls-class-plugin: Add logs
Don't hard-wire handlers, but make sure all handlers are associated to a PluginDescriptor, s.t. we can check that the handler is actually enabled for a given request.
* Fix parameter switch-up
* Generalise file extension handling for plugins
NotificationHandler now distinguishes between different file extensions
RequestHandler distinguishes between different file extensions
* Introduce PluginMethod Typeclass hierarchy
The hierarchy looks as follows:
PluginMethod (pluginEnabled)
|
-----------------------------------
| |
PluginRequestMethod PluginNotificationMethod
* Add example plugin
* Improve documentation for plugins
* Simplify Plugin Handling code
Co-authored-by: Jana Chadt <[email protected]>
Co-authored-by: Jana Chadt <[email protected]>
Co-authored-by: Fendor <[email protected]>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
* hls-class-plugin enhancement * Comment to be compatible * Add HasSrcSpan instances * hls-class-plugin enhancement * Comment to be compatible * Add HasSrcSpan instances * Compitable fix * Qualified name * Fix compatibility * Resolve reviews * Rename test files Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
* HLint partial functions * Delete commented out stuff * Delete flag-based warnings, unclear they add much * Delete DA-specific hints * Delete extra cpp args * Delete extension options relating to dead build system * Don't bother trying to restrict CPP for now, it's everywhere * Make the hlint job fail if there are any errors * Fix for rebase, add unsafePerformIO and fold1 variants * Add some more indexing functions * Try turning off hlint on this test file * Add .hlint.yaml file for hls-hlint-plugin Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
* Make wrapper a LSP on failure * Fix incorrect imports * revert import block for smaller diff * add missing imports * Fix: callProcess on win32 machines not called * import container only on win32 * add missing liftIO Co-authored-by: Pepe Iborra <[email protected]>
* haskell#2414 fix new import position * fix auto import for ghc version < 9.2 * re-fix it for ghc-9.2 * handle comments * add more comments * reword comments of findPositionNoImports Co-authored-by: Pepe Iborra <[email protected]> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Motivation is to be able to sub-in our own GHC version, and I don't know how to / if it's possible to do that when everything is defined inside a flake. Ideally would have the flake use existing non-flake definitions. Currently uses the .mwb suffix for haskell packages; should remove that or abstract it.
Closed
|
Hmm this process should be documented - I think it's probably good that we have a For the weird regex thing and gitignore, that's.. hopefully something that is going to be fixed upstream of HLS. But really it's a bug of some sort in how So this PR should ideally get Does that make sense? |
|
That |
matthewbauer
approved these changes
Jun 27, 2022
|
Resolution:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Most of the changes in this repo have been upstreamed, so I've pulled changes from upstream and rebased on top of them.
This leaves only a few commits specific to the Mercury fork:
Of these, the sha256 hashes in
hls.nixare the new feature here, for supporting Nix flakes in mwb: https://github.com/MercuryTechnologies/mercury-web-backend/pull/9571