Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sync local changes on top of upstream #4

Merged
merged 29 commits into from
Jun 27, 2022
Merged

Conversation

9999years
Copy link
Member

No description provided.

parsonsmatt and others added 29 commits June 11, 2022 06:45
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.
* 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.
@9999years 9999years merged commit 2796d82 into mercury/master Jun 27, 2022
@9999years 9999years deleted the rbt/local-changes branch June 27, 2022 19:40
@9999years 9999years restored the rbt/local-changes branch June 27, 2022 19:40
@9999years 9999years deleted the rbt/local-changes branch June 27, 2022 19:41
@9999years 9999years mentioned this pull request Jun 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.