The Wayback Machine - https://web.archive.org/web/20201218054705/https://github.com/haskell/haskell-ide-engine/issues/1506
Skip to content
This repository has been archived by the owner. It is now read-only.

/ haskell-ide-engine Archived

Automatic extension detection from package.yaml for Floskell #1506

Open
Krantz-XRF opened this issue Dec 29, 2019 · 4 comments
Open

Automatic extension detection from package.yaml for Floskell #1506

Krantz-XRF opened this issue Dec 29, 2019 · 4 comments
Labels
good first issue

Comments

@Krantz-XRF
Copy link

@Krantz-XRF Krantz-XRF commented Dec 29, 2019

I have several extensions enabled in my package.yaml file in the default-extensions field (e.g. DerivingStrategies), so floskell fails to parse the source file (on seeing deriving stock for example) and reports a syntax error.

Is there any possibility that we automatically detect the default-extensions field in package.yaml file and pass them to floskell? Or perhaps by default enabling some extensions that in general don't break otherwise well-formed programs (e.g. DerivingStrategies, StandaloneDeriving, etc.)?
@Krantz-XRF
Copy link
Author

@Krantz-XRF Krantz-XRF commented Dec 29, 2019

I see that extensions can be specified in floskell configuration files, but two copies of the default extensions seem a bit difficult to maintain. If the extensions can be automatically extracted from package.yaml and passed to floskell, some human labour would be saved.
@fendor
Copy link
Collaborator

@fendor fendor commented Dec 29, 2019

I think that should be rather trivial now. We have access to the DynFlags within IdeGhcM, and the used language extensions are in the DynFlags.
@bubba
Copy link
Collaborator

@bubba bubba commented Dec 29, 2019

Might this need to be addressed upstream?
@fendor
Copy link
Collaborator

@fendor fendor commented Dec 29, 2019 •
edited

It can be addressed upstream, but we can easily fix it here, imo. Might also be useful for #1374
EDIT: unless floskell maintainers say they want to support that, I think adding this upstream is just re-implementing what we already know here. We know the exact flags used to compile a file, including the language extensions. floskell would need to re-implement all the stuff we are doing with the cradles.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
good first issue
3 participants
@bubba @fendor @Krantz-XRF
You can’t perform that action at this time.