kowainik / extensions Goto Github PK

I hit this problem when trying to use the getPackageExtentions function pointing to a cabal file that is not my current directory, but I can also exhibit it using the CLI:

…/ext-stats $ extensions --cabal-file-path hackage/3dmodels-0.3.0/*.cabal 
  ⓘ Extensions for each module combined with 'default-extensions'
…/ext-stats $ cd hackage/3dmodels-0.3.0
…/hackage/3dmodels-0.3.0 $ extensions --cabal-file-path *.cabal
  ⓘ Extensions for each module combined with 'default-extensions'
Graphics/Model/DirectX.hs
    OverloadedStrings
    RecordWildCards
Graphics/Model/MikuMikuDance.hs
Graphics/Model/MikuMikuDance/Loader.hs
    OverloadedStrings
Graphics/Model/MikuMikuDance/Types.hs
Graphics/Model/Obj.hs
    OverloadedStrings
    TupleSections

I would expect it to find the source code relative to the given cabal file.

Also, as a feature request, it might be nice if I can just pass a path to a directory, and it will use the (existing) logic to find the .cabal file therein.

Created a separate issue for GHC 9.0 (#73) and GHC 9.2. We use GHC API and Cabal API so some amount of non-trivial changes is required to make this library support newer GHC versions.

Sometimes it's helpful to have a function:

isEnabled :: Extension -> Set OnOffExtension -> Bool

That checks whether there's On for the particular given extension.

Does it sound useful? For now, I propose not to think about the fact that some extensions can imply other extensions, this is another whole story..

They are not constructors of the Extension type, but they are specified as {-# LANGUAGE #-} pragmas.

Could return the map of stanzas' directory to list of enabled extensions

Hi, there have been a few fixes on the main git branch, that have not yet been released in a version on Hackage. These would be useful to have

Thank you

https://github.com/actions/setup-haskell (unmaintained) should be replaced with https://github.com/haskell/actions/tree/main/setup.

After #45 we have showOnOffExtension to pretty-print OnOffExtension. In Extensions.Parser we have readOnOffExtenion function. We can do the following:

1. Move readOnOffExtenion to Extensions.OnOff.
2. Implement property-based roundtrip test for showOnOffExtension and readOnOffExtension.

We need to add tests both to Cabal, Parser and combined functions that should contain SafeHaskell extensions. Specifically in each we need to check:

Module tests

• One SafeHaskell extension results to Just extension
• Several identical SafeHaskell extensions results to Just extension
• Several different SafeHaskell extensions result to an error (SafeExtensionsConflict)
• No Safe Haskell Extension doesn't parse

Cabal tests

• One SafeHaskell extension in default-extensions results to Just extension
• Conflicting SafeHaskell extensions in a single stanza
• SafeHaskell extensions in different stanzas do not conflict

, hspec-hedgehog ^>= 0.0.1

Can this be changed to support 0.1.* ? https://hackage.haskell.org/package/hspec-hedgehog
Thank you

Blocked on

• hedgehogqa/haskell-hedgehog#502

Language extensions Safe, Unsafe and Trustworthy are special, because:

1. They are parsed by both Cabal and GHC.
2. But they don't have a corresponding constructor of the GHC Extension. Even though they are specified using the {-# LANGUAGE #-} pragma, they are not recognized as extensions. They are stored in DynFlags as the safeHaskell field of type SafeHaskellMode.
3. They also don't follow the No scheme of disabling/enabling extensions.

It would be nice to report these extensions as used, but it's not clear how to model them as data types. Current behaviour: they are ignored during parsing.

Currently extensions works only with Haskell2010

New constructor like ModuleDoesn'tExist FilePath in the ExtensionsError data type.

Some Haskell packages don't have the hs-source-dirs field in their .cabal files. In such packages, modules are placed directly on top-level. One example of such package:

• https://github.com/haskell/base64-bytestring/blob/master/base64-bytestring.cabal

So instead of src/Data/ByteString/Base64.hs file, you have simply Data/ByteString/Base64.hs. Current implementation of parseCabalExtensions will return empty map in such cases. But I guess it needs to be patched. I see packages with such structure from time to time in the Haskell ecosystem.

CUSKs was added in 8.10.1 and enabled by default.

References:

1. https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/poly_kinds.html#complete-user-supplied-kind-signatures-and-

.. extension:: CUSKs
    :shortdesc: Enable detection of complete user-supplied kind signatures.

    :since: 8.10.1
    :status: Included in :extension:`Haskell98`, :extension:`Haskell2010`

2. https://gitlab.haskell.org/ghc/ghc/-/blob/7574659452a864e762fa812cb38cf15f70d85617/docs/users_guide/exts/control.rst

. extension:: Haskell2010
    :shortdesc: Use the Haskell 2010 language variant.

    Compile Haskell 2010 language variant. Enables the
    following language extensions:

    .. hlist::

     * :extension:`CUSKs`
     * :extension:`DatatypeContexts`
     * :extension:`DoAndIfThenElse`
     * :extension:`EmptyDataDecls`
     * :extension:`FieldSelectors`
     * :extension:`ForeignFunctionInterface`
     * :extension:`ImplicitPrelude`
     * :extension:`MonomorphismRestriction`
     * :extension:`PatternGuards`
     * :extension:`RelaxedPolyRec`
     * :extension:`StarIsType`
     * :extension:`TraditionalRecordSyntax`

We could achieve this by making the toGhcExtension case end with a wildcard pattern mapping to Nothing.

On means that extension is enabled. Off — it has No prefixed and disabled.

• About library
• How to use the library
• How to install/use the tool

Discovered while working on this HLS PR: haskell/haskell-language-server#4023, related to these issues:

• haskell/haskell-language-server#3174
• kowainik/stan#556

Stan, via extensions, appears to be prepending the hs-source-dirs from the .cabal file verbatim onto the module name. This means if the .cabal file uses / as its path separators, the returned file paths (and associated extension map) will be broken for Windows users.

For example, if your cabal file has:

  hs-source-dirs: extension-tests/language-pragma

... then the resulting Map key winds up looking like this for Windows users:

extension-tests/language-pragma\\LanguagePragmaTest.hs

This results in Map lookups missing, which in turn results in Stan not recognizing any of a project's enabled extensions. (One of the causes for the above-mentioned HLS issue.)

From a quick look, I think the issue might be happening around here somewhere. (I do see some Cabal version checks, not sure how those play into this...)

It seems that extensions can be thown off by comments before the pragma list, as in these files:

• http://hackage.haskell.org/package/executable-path-0.0.3.1/docs/src/System-Environment-Executable.html
• http://hackage.haskell.org/package/extra-1.6.8/docs/src/Data.Tuple.Extra.html

(small selection… I am running your tool on all hackage package’s latest versions, so I can provide more.)

Currently it's not easy to test cabal parsing functions only on cabal-files, since the function requires IO to check whether the module actually exist. I think cabal parsing functions can be patched, and I see a few ways to do this.

1. Pass a function of type Monad m => FilePath -> m Bool that checks whether the module exist. So in IO we will pass the doesFileExist function, and in tests we will pass const $ pure True (or something more sophisticated for better testing).
2. Read all files recursively from all hs-source-dirs using a package like dir-traverse at the beginning, and then instead of checking whether the file exist, we can just check whether it's in the given list.

Option 1 is easier to implement and won't require to have a separate dependency. But maybe Option 2 sounds better in theory. Also, maybe I'm missing something else...

@vrom911 What do you think?