GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-02-06T15:15:15Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/24399-hide-package doesn't play nice with -package-env2024-02-06T15:15:15ZSimon Hengelsol@typeful.net-hide-package doesn't play nice with -package-env## Summary
When I use `-hide-package` in combination with `-package-env` then it seems to have no effect.
## Steps to reproduce
With `cabal-install-3.10.2.1`:
```
$ tree
.
├── foo.cabal
└── src
└── Prelude.hs
```
```cabal
cabal-v...## Summary
When I use `-hide-package` in combination with `-package-env` then it seems to have no effect.
## Steps to reproduce
With `cabal-install-3.10.2.1`:
```
$ tree
.
├── foo.cabal
└── src
└── Prelude.hs
```
```cabal
cabal-version: 3.8
name: foo
version: 0.0.0
library
build-depends: base
mixins: base (Prelude as BasePrelude)
hs-source-dirs: src
exposed-modules: Prelude
```
```haskell
{-# LANGUAGE NoImplicitPrelude #-}
module Prelude where
import BasePrelude
foo :: Int
foo = 23
```
```
$ cabal install --package-env=package.env --lib
$ ghci -package-env=package.env -hide-package=base
ghci> import Prelude
<no location info>: error: [GHC-45102]
Ambiguous module name ‘Prelude’.
it was found in multiple packages: base-4.19.0.0 foo-0.0.0
```
## Expected behavior
The module `Prelude` from package `foo` is used.
## Environment
* GHC version used: 9.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/23653Add `-fprint-unit-ids` and hide printing of unit-ids by default.2023-08-14T09:09:25ZOleg GrenrusAdd `-fprint-unit-ids` and hide printing of unit-ids by default.Output like
```
... (servant-0.19.1-2766f5fde1349996d1634ebb37647b1723dacd28547ecaafe0e93e4cfa5eec79:Servant.API.ReqBody.ReqBody
'[servant-0.19.1-2766f5fde1349996d1634ebb37647b1723dacd28547ecaafe0e93e4cfa5eec79:Servant.API.ContentTypes....Output like
```
... (servant-0.19.1-2766f5fde1349996d1634ebb37647b1723dacd28547ecaafe0e93e4cfa5eec79:Servant.API.ReqBody.ReqBody
'[servant-0.19.1-2766f5fde1349996d1634ebb37647b1723dacd28547ecaafe0e93e4cfa5eec79:Servant.API.ContentTypes.JSON]
```
is usually not helpful.
I think hiding full unit-ids by default would make output a lot cleaner (when things are not in scope).
A middleground would be to print *package name* (which I guess is somewhat easily available as `PackageImports` uses it), i.e.
```
... (servant:Servant.API.ReqBody.ReqBody '[servant:Servant.API.ContentTypes.JSON]
```Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/23131ghc type mismatch due to different package versions2023-10-28T08:03:10ZFrancesco Occhipintighc type mismatch due to different package versions## Summary
We stumbled upon the following:
```
• Couldn't match type ‘bytestring-0.10.8.2:Data.ByteString.Internal.ByteString’
with ‘ByteString’
NB: ‘ByteString’
is defined in ‘Data.ByteString...## Summary
We stumbled upon the following:
```
• Couldn't match type ‘bytestring-0.10.8.2:Data.ByteString.Internal.ByteString’
with ‘ByteString’
NB: ‘ByteString’
is defined in ‘Data.ByteString.Internal.Type’
in package ‘bytestring-0.11.4.0’
‘bytestring-0.10.8.2:Data.ByteString.Internal.ByteString’
is defined in ‘Data.ByteString.Internal’
in package ‘bytestring-0.10.8.2’
Expected type: Field -> Parser Day
Actual type: ByteString -> Parser Day
• In the expression: parseDate
In an equation for ‘parseField’: parseField = parseDate
In the instance declaration for ‘FromField Day’
```
This seems to be due to `cassava` relying on `bytestring` 0.10, while the type in scope and related functions come from an installed `bytestring` 0.11.
Unfortunately, the `PackageImports` syntax does not allow to specify a package version.
We could try to select the desired package by using the compiler's options, but `-hide-all-packages` won't help because it prevents some locally installed packages to access their dependencies. `-hide-package bytestring-0.11.4.2`, on the other hand, fails with the surprising error:
```
<command line>: cannot satisfy -hide-package bytestring-0.11.4.2
(use -v for more information)
```
Since we just want to hide a package, we would expect no errors even if the package was not visible. Anyway this is just some temporary puzzlement, as it turns out that we wrote the version wrong, so the error is arguably helpful.
Once the right version is specified, the compiler starts and mostly works, although it seems to still fail at some stage, between Renamer and Upsweep, with the same problem:
```
Ambiguous module name ‘Data.ByteString.Lazy’:
it was found in multiple packages:
bytestring-0.10.8.2 bytestring-0.11.4.0
```
The compiler version is 8.6.5. Before updating i would be interested to know whether this has been fixed in a later version. Furthermore, since this use case touched a diverse array of limitations, i thought it might be worth issuing anyway.
Here the complete error including some contextual lines:
```
*** Parser [Lumaposta]:
!!! Parser [Lumaposta]: finished in 2.81 milliseconds, allocated 4.923 megabytes
*** Renamer/typechecker [Lumaposta]:
!!! Renamer/typechecker [Lumaposta]: finished in 25.23 milliseconds, allocated 12.681 megabytes
lumaposta.hs:9:1: error:
Ambiguous module name ‘Data.ByteString’:
it was found in multiple packages:
bytestring-0.10.8.2 bytestring-0.11.4.0
|
9 | import Data.ByteString (ByteString)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
lumaposta.hs:16:1: error:
Ambiguous module name ‘Data.ByteString’:
it was found in multiple packages:
bytestring-0.10.8.2 bytestring-0.11.4.0
|
16 | import qualified Data.ByteString as ByteString
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
lumaposta.hs:17:1: error:
Ambiguous module name ‘Data.ByteString.Lazy’:
it was found in multiple packages:
bytestring-0.10.8.2 bytestring-0.11.4.0
|
17 | import qualified Data.ByteString.Lazy as Lazy
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
lumaposta.hs:18:1: error:
Ambiguous module name ‘Data.ByteString.Char8’:
it was found in multiple packages:
bytestring-0.10.8.2 bytestring-0.11.4.0
|
18 | import qualified Data.ByteString.Char8 as Char8
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Upsweep partially successful.
*** Deleting temp files:
Deleting:
link(batch): upsweep (partially) failed OR
Main.main not exported; not linking.
*** Deleting temp files:
Deleting:
*** Deleting temp dirs:
Deleting:
```
## Environment
* GHC version used: 8.6.5Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/22960EPS contention may be slowing down parallel make2023-02-27T20:15:03ZTeo CamarasuEPS contention may be slowing down parallel make### Summary
I think it's likely that contention of the EPS is blocking parallel make from reaching its full potential on large shallow module graphs.
The EPS is stored in a global IORef and is regularly checked during typechecking.
If a...### Summary
I think it's likely that contention of the EPS is blocking parallel make from reaching its full potential on large shallow module graphs.
The EPS is stored in a global IORef and is regularly checked during typechecking.
If an interface hasn't yet been loaded, then it will be loaded, typecheched (potentially loading further interfaces), and then atomically merged with the current value of the EPS.
From a quick glance at the code I'm seeing two potential issues:
1) Duplicated work due to two threads racing:
In a situation where two threads both discover that an interface is missing from the EPS, I think, they will duplicate work to load it.
2) Atomically updating the EPS blocks reads:
AFAIK using `atomicModifyIORef'` blocks reads, as it updates the IORef with a thunk that it then evaluates. While the thunk is under evaluation, other threads will be blocked if they try to look at it.
I say potential issues because I haven't done enough investigating to confirm if this is actually an issue.
I'll try to do that in the next couple of weeks and come up with some strategies to mitigate it if it does turn out to be a problem.
### Context
I was led to the EPS by looking at the DWARF decoded stacks of threads blocking on blackholes while compiling `Cabal`.
Code that was looking things up in the EPS stood out to me. I used this branch of ghc https://gitlab.haskell.org/teo/ghc/-/commits/wip/blackhole-introspectionBen GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/22732Don't reuse `hsLibraries` field of InstalledPackageInfo for native libraries2023-01-26T21:42:58ZBen GamariDon't reuse `hsLibraries` field of InstalledPackageInfo for native librariesIn https://gitlab.haskell.org/ghc/ghc/-/issues/22564#note_468545 we noted that users of the `extra-bundled-libraries` field are saddled with the unfortunate requirement of naming their native libraries with a `libC` prefix (specified in ...In https://gitlab.haskell.org/ghc/ghc/-/issues/22564#note_468545 we noted that users of the `extra-bundled-libraries` field are saddled with the unfortunate requirement of naming their native libraries with a `libC` prefix (specified in the Cabal [reference documentation](https://cabal.readthedocs.io/en/stable/cabal-package.html#pkg-field-extra-bundled-libraries)).
The requirement is due to the strange implementation of `extra-bundled-libraries`: "bundled" libraries are added to the `hsLibraries` field of `InstalledPackageInfo`, leaving the runtime linker with an ambiguity regarding whether the library is a Haskell object (in which case it may need a "way" suffix in its name) or native object. The required `libHS`/`libC` prefix allows the linker to resolve this ambiguity.
IMHO it would be much better if `extra-bundled-libraries` were instead implemented in terms of a new `InstalledPackageInfo` field, eliminating the ambiguity by construction.https://gitlab.haskell.org/ghc/ghc/-/issues/21170Accommodate build systems with their own notion of package names2022-03-09T17:59:06ZAndrew PritchardAccommodate build systems with their own notion of package names## Motivation
Large-scale multi-language build systems like Bazel have their own notion of package identity different from Cabal's flat alphanumeric-plus-hyphens package names. When building Haskell code with these systems, collections...## Motivation
Large-scale multi-language build systems like Bazel have their own notion of package identity different from Cabal's flat alphanumeric-plus-hyphens package names. When building Haskell code with these systems, collections of Haskell modules might have names like `//some/path:my_library` rather than, say, `distributive`. Current integrations with these systems have to work around the package name validation, e.g. by using only the last path component (https://github.com/tweag/rules_haskell/blob/dfd0161264b3e1ca8e47c30ef258d50e754570fc/haskell/private/pkg_id.bzl#L45) or encoding the label into the set of allowed characters (https://github.com/google/cabal2bazel/blob/master/bzl/private/package.bzl#L32-L55), leading to ugly and confusing package names like `someS-SpathS-SmyU-Ulibrary` in various contexts (compiler command lines, package-qualified import syntax, occasionally type errors, and probably others).
More generally, complex builds may identify components with hierarchical paths, and it'd be good to allow them to use their own naming scheme for the corresponding GHC packages without needing to encode them into a highly-restricted set of characters.
## Proposal
Change GHC and (if necessary) the Cabal library to allow non-Cabal build systems to use their own preferred formatting for package names (without changing the package naming rules for Hackage or the Cabal build tool). An existing Bazel-specific patch already exists, which accepts Bazel label syntax as package names in GHC flags, package-qualified import syntax, and the Cabal parsers, but it might need to be more general-purpose in order to be merged.https://gitlab.haskell.org/ghc/ghc/-/issues/20888MHU: Package thinning/renaming not supported properly2023-07-18T07:32:47ZMatthew PickeringMHU: Package thinning/renaming not supported properlyThe way multiple home units calculate dependencies currently ignores any thinning/renaming specifications. This feature is rarely used so it doesn't matter too much for testing but will be subtly broken if anyone does try and use it.
S...The way multiple home units calculate dependencies currently ignores any thinning/renaming specifications. This feature is rarely used so it doesn't matter too much for testing but will be subtly broken if anyone does try and use it.
See `selectHomeUnits` in `GHC.Unit.State` for the start of where needs to be changed. Then the thinning specification needs to be carried all the way through to the Finder logic and applied accordingly.
Documentation - https://downloads.haskell.org/~ghc/8.8.1/docs/html/users_guide/packages.html#thinning-and-renaming-moduleshttps://gitlab.haskell.org/ghc/ghc/-/issues/20806Document -package-env correctly2021-12-14T08:43:20ZRichard Eisenbergrae@richarde.devDocument -package-env correctlyFor a few GHCs now, I'm used to seeing a note as GHCi launches that it has loaded my default package environment file, in `~/.ghc/arch-version/environments/default`. Today, when working in GHC 9.2.1, I was surprised that some package was...For a few GHCs now, I'm used to seeing a note as GHCi launches that it has loaded my default package environment file, in `~/.ghc/arch-version/environments/default`. Today, when working in GHC 9.2.1, I was surprised that some package wasn't available, and so I looked for this line and was surprised not to find it.
Yet the [documentation](https://downloads.haskell.org/ghc/latest/docs/html/users_guide/packages.html#package-environments) still says that it loads this default.
I think the documentation should be updated, and a release note added.https://gitlab.haskell.org/ghc/ghc/-/issues/20759Wire up library-dirs-static and extra-libraries-static in GHC2021-12-12T07:36:38ZAlex BiehlWire up library-dirs-static and extra-libraries-static in GHCWith the new fields `library-dirs-static` and `extra-libraries-static` InstalledPackageInfo supports a way to specify libraries for static linking separately from `extra-libraries`/`library-dirs`. This allows us to switch smoothly betwee...With the new fields `library-dirs-static` and `extra-libraries-static` InstalledPackageInfo supports a way to specify libraries for static linking separately from `extra-libraries`/`library-dirs`. This allows us to switch smoothly between dynamic and static linking of system libraries.
Cabal and cabal-install already do the right thing and populate the new fields when using pkg-config-depends.
What's left is the GHC side of things:
- [x] Bump GHC's Cabal dependency to support `library-dirs-static` and `extra-libraries-static`. This has been done.
- [ ] Introduce `library-dirs-static` and `extra-libraries-static` to ghc-pkg
- [ ] When statically linking an executable consult above fields for extra libraries to link (instead of always consulting `extra-libraries`/`library-dirs` as we do now)https://gitlab.haskell.org/ghc/ghc/-/issues/19370ghc: panic!: expectJust, called at compiler/main/Packages.hs:433:5 in ghc:Pac...2021-06-04T11:08:27ZJens Petersenghc: panic!: expectJust, called at compiler/main/Packages.hs:433:5 in ghc:Packages## Summary
ghc-8.10 is crashing when compiling/linking(?) a medium-sized executable for me.
With both ghc-8.10.3 and ghc-8.10.4 on Fedora 33 x86_64:
```
[41 of 42] Compiling Paths_fbrnch
[42 of 42] Compiling Main [Distribution.Fedora.B...## Summary
ghc-8.10 is crashing when compiling/linking(?) a medium-sized executable for me.
With both ghc-8.10.3 and ghc-8.10.4 on Fedora 33 x86_64:
```
[41 of 42] Compiling Paths_fbrnch
[42 of 42] Compiling Main [Distribution.Fedora.Branch changed]
ghc: panic! (the 'impossible' happened)
(GHC version 8.10.3:
expectJust getPackageDetails
CallStack (from HasCallStack):
error, called at compiler/utils/Maybes.hs:57:27 in ghc:Maybes
expectJust, called at compiler/main/Packages.hs:433:5 in ghc:Packages
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```
I originally mentioned this in #18284 but this backtrace looks of different origin so I am reporting here now separately.
## Steps to reproduce
`stack --resolver lts-17 build fbrnch`
## Expected behavior
Compile the program without panicking (like 8.8.4 does successfully).
Not having to re-run the build to get it to complete.
I don't feel confident with updating Fedora to 8.10 with this issue existing,
though admittedly this is not a Fedora ghc build.
## Environment
* GHC version used: 8.10.4
Optional:
* Operating System: Fedora 33
* System Architecture: x86_64https://gitlab.haskell.org/ghc/ghc/-/issues/19330Improve `ModOrigin: hidden module redefined` crash report2021-02-23T19:54:21ZSergei TrofimovichImprove `ModOrigin: hidden module redefined` crash report## Summary
Sometimes packages clash in module namespace in unobvious ways. GHC has a hard time loading those and it's very hard to figure out what module actually breaks things.
## Steps to reproduce
I don't know precise set of instal...## Summary
Sometimes packages clash in module namespace in unobvious ways. GHC has a hard time loading those and it's very hard to figure out what module actually breaks things.
## Steps to reproduce
I don't know precise set of installed packages needed to trigger the failure, but it looks like that:
```
./setup haddock --hyperlink-source
Preprocessing library for haskell-lsp-types-0.22.0.0..
Running Haddock on library for haskell-lsp-types-0.22.0.0..
Warning: --source-* options are ignored when --hyperlinked-source is enabled.
Haddock coverage:
33% ( 1 / 3) in 'Language.Haskell.LSP.Types.Constants'
Missing documentation for:
Module header
customModifier (src/Language/Haskell/LSP/Types/Constants.hs:13)
src/Language/Haskell/LSP/Types/MarkupContent.hs:15:1: warning: [-Wunused-imports]
The import of ‘Data.Monoid’ is redundant
except perhaps to import instances from ‘Data.Monoid’
To import instances alone, use: import Data.Monoid()
|
15 | import Data.Monoid ((<>))
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Warning: 'Hover' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: 'ParameterInfo' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: 'CompletionItem' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: 'plaintext' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: 'markdown' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: 'typescript' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
src/Language/Haskell/LSP/Types/Uri.hs:27:1: warning: [-Wunused-imports]
The import of ‘isPrefixOf’ from module ‘Data.List’ is redundant
|
27 | import Data.List (isPrefixOf, stripPrefix)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Warning: 'comment' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: 'region' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: '_range' is ambiguous. It is defined
* at src/Language/Haskell/LSP/Types/Location.hs:95:7
* at src/Language/Haskell/LSP/Types/Symbol.hs:220:7
You may be able to disambiguate the identifier by qualifying it or
by specifying the type/value namespace explicitly.
Defaulting to the one defined at src/Language/Haskell/LSP/Types/Symbol.hs:220:7
0% ( 0 / 2) in 'Language.Haskell.LSP.Types.Utils'
Missing documentation for:
Module header
rdrop (src/Language/Haskell/LSP/Types/Utils.hs:5)
Warning: '_title' is ambiguous. It is defined
* at src/Language/Haskell/LSP/Types/Window.hs:145:7
* at src/Language/Haskell/LSP/Types/Window.hs:264:4
You may be able to disambiguate the identifier by qualifying it or
by specifying the type/value namespace explicitly.
Defaulting to the one defined at src/Language/Haskell/LSP/Types/Window.hs:264:4
Warning: '_percentage' is ambiguous. It is defined
* at src/Language/Haskell/LSP/Types/Window.hs:367:5
* at src/Language/Haskell/LSP/Types/Window.hs:282:5
You may be able to disambiguate the identifier by qualifying it or
by specifying the type/value namespace explicitly.
Defaulting to the one defined at src/Language/Haskell/LSP/Types/Window.hs:282:5
src/Language/Haskell/LSP/Types/WorkspaceEdit.hs:9:1: warning: [-Wunused-imports]
The import of ‘Data.Monoid’ is redundant
except perhaps to import instances from ‘Data.Monoid’
To import instances alone, use: import Data.Monoid()
|
9 | import Data.Monoid ((<>))
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Warning: 'falsy' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: 'insertText' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: 'newText' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: 'textEdit' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: 'triggerCharacters' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: 'falsy' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: '_command' is ambiguous. It is defined
* at src/Language/Haskell/LSP/Types/Command.hs:41:7
* at src/Language/Haskell/LSP/Types/CodeAction.hs:275:7
You may be able to disambiguate the identifier by qualifying it or
by specifying the type/value namespace explicitly.
Defaulting to the one defined at src/Language/Haskell/LSP/Types/CodeAction.hs:275:7
Warning: 'WorkspaceEdit' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: 'File' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: 'Array' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: 'SignatureInformation' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: 'true' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: 'startCharacter' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
Warning: 'endCharacter' is out of scope.
If you qualify the identifier, haddock can try to link it anyway.
0% ( 0 /200) in 'Language.Haskell.LSP.Types.Lens'
Missing documentation for:
Module header
HasDocumentChanges (src/Language/Haskell/LSP/Types/Lens.hs:28)
HasDynamicRegistration (src/Language/Haskell/LSP/Types/Lens.hs:29)
HasValueSet (src/Language/Haskell/LSP/Types/Lens.hs:31)
HasSymbolKind (src/Language/Haskell/LSP/Types/Lens.hs:32)
HasApplyEdit (src/Language/Haskell/LSP/Types/Lens.hs:34)
HasConfiguration (src/Language/Haskell/LSP/Types/Lens.hs:34)
HasDidChangeConfiguration (src/Language/Haskell/LSP/Types/Lens.hs:34)
HasDidChangeWatchedFiles (src/Language/Haskell/LSP/Types/Lens.hs:34)
HasExecuteCommand (src/Language/Haskell/LSP/Types/Lens.hs:34)
HasSymbol (src/Language/Haskell/LSP/Types/Lens.hs:34)
HasWorkspaceEdit (src/Language/Haskell/LSP/Types/Lens.hs:34)
HasWorkspaceFolders (src/Language/Haskell/LSP/Types/Lens.hs:34)
HasDidSave (src/Language/Haskell/LSP/Types/Lens.hs:35)
HasWillSave (src/Language/Haskell/LSP/Types/Lens.hs:35)
HasWillSaveWaitUntil (src/Language/Haskell/LSP/Types/Lens.hs:35)
HasCommitCharactersSupport (src/Language/Haskell/LSP/Types/Lens.hs:37)
HasDeprecatedSupport (src/Language/Haskell/LSP/Types/Lens.hs:37)
HasDocumentationFormat (src/Language/Haskell/LSP/Types/Lens.hs:37)
HasPreselectSupport (src/Language/Haskell/LSP/Types/Lens.hs:37)
HasSnippetSupport (src/Language/Haskell/LSP/Types/Lens.hs:37)
HasTagSupport (src/Language/Haskell/LSP/Types/Lens.hs:37)
HasCompletionItem (src/Language/Haskell/LSP/Types/Lens.hs:39)
HasCompletionItemKind (src/Language/Haskell/LSP/Types/Lens.hs:39)
HasContextSupport (src/Language/Haskell/LSP/Types/Lens.hs:39)
HasContentFormat (src/Language/Haskell/LSP/Types/Lens.hs:40)
HasSignatureInformation (src/Language/Haskell/LSP/Types/Lens.hs:42)
HasHierarchicalDocumentSymbolSupport (src/Language/Haskell/LSP/Types/Lens.hs:46)
HasCodeActionKind (src/Language/Haskell/LSP/Types/Lens.hs:54)
HasCodeActionLiteralSupport (src/Language/Haskell/LSP/Types/Lens.hs:55)
HasPrepareSupport (src/Language/Haskell/LSP/Types/Lens.hs:59)
HasRelatedInformation (src/Language/Haskell/LSP/Types/Lens.hs:60)
HasCodeAction (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasCodeLens (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasColorProvider (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasCompletion (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasDefinition (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasDocumentHighlight (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasDocumentLink (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasDocumentSymbol (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasFoldingRange (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasFormatting (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasHover (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasImplementation (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasOnTypeFormatting (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasPublishDiagnostics (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasRangeFormatting (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasReferences (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasRename (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasSignatureHelp (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasSynchronization (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasTypeDefinition (src/Language/Haskell/LSP/Types/Lens.hs:62)
HasExperimental (src/Language/Haskell/LSP/Types/Lens.hs:63)
HasTextDocument (src/Language/Haskell/LSP/Types/Lens.hs:63)
HasWindow (src/Language/Haskell/LSP/Types/Lens.hs:63)
HasWorkspace (src/Language/Haskell/LSP/Types/Lens.hs:63)
HasCapabilities (src/Language/Haskell/LSP/Types/Lens.hs:67)
HasInitializationOptions (src/Language/Haskell/LSP/Types/Lens.hs:67)
HasProcessId (src/Language/Haskell/LSP/Types/Lens.hs:67)
HasRootPath (src/Language/Haskell/LSP/Types/Lens.hs:67)
HasRootUri (src/Language/Haskell/LSP/Types/Lens.hs:67)
HasTrace (src/Language/Haskell/LSP/Types/Lens.hs:67)
HasRetry (src/Language/Haskell/LSP/Types/Lens.hs:68)
HasAllCommitCharacters (src/Language/Haskell/LSP/Types/Lens.hs:69)
HasResolveProvider (src/Language/Haskell/LSP/Types/Lens.hs:69)
HasTriggerCharacters (src/Language/Haskell/LSP/Types/Lens.hs:69)
HasRetriggerCharacters (src/Language/Haskell/LSP/Types/Lens.hs:70)
HasFirstTriggerCharacter (src/Language/Haskell/LSP/Types/Lens.hs:72)
HasMoreTriggerCharacter (src/Language/Haskell/LSP/Types/Lens.hs:72)
HasCommands (src/Language/Haskell/LSP/Types/Lens.hs:74)
HasIncludeText (src/Language/Haskell/LSP/Types/Lens.hs:75)
HasChange (src/Language/Haskell/LSP/Types/Lens.hs:76)
HasOpenClose (src/Language/Haskell/LSP/Types/Lens.hs:76)
HasSave (src/Language/Haskell/LSP/Types/Lens.hs:76)
HasChangeNotifications (src/Language/Haskell/LSP/Types/Lens.hs:77)
HasSupported (src/Language/Haskell/LSP/Types/Lens.hs:77)
HasCodeActionProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasCodeLensProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasCompletionProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasDefinitionProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasDocumentFormattingProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasDocumentHighlightProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasDocumentLinkProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasDocumentOnTypeFormattingProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasDocumentRangeFormattingProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasDocumentSymbolProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasExecuteCommandProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasFoldingRangeProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasHoverProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasImplementationProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasReferencesProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasRenameProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasSignatureHelpProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasTextDocumentSync (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasTypeDefinitionProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasWorkspaceSymbolProvider (src/Language/Haskell/LSP/Types/Lens.hs:79)
HasId (src/Language/Haskell/LSP/Types/Lens.hs:81)
HasMethod (src/Language/Haskell/LSP/Types/Lens.hs:81)
HasRegisterOptions (src/Language/Haskell/LSP/Types/Lens.hs:81)
HasRegistrations (src/Language/Haskell/LSP/Types/Lens.hs:82)
HasWatchers (src/Language/Haskell/LSP/Types/Lens.hs:83)
HasGlobPattern (src/Language/Haskell/LSP/Types/Lens.hs:84)
HasKind (src/Language/Haskell/LSP/Types/Lens.hs:84)
HasWatchChange (src/Language/Haskell/LSP/Types/Lens.hs:85)
HasWatchCreate (src/Language/Haskell/LSP/Types/Lens.hs:85)
HasWatchDelete (src/Language/Haskell/LSP/Types/Lens.hs:85)
HasDocumentSelector (src/Language/Haskell/LSP/Types/Lens.hs:86)
HasUnregistrations (src/Language/Haskell/LSP/Types/Lens.hs:88)
HasSettings (src/Language/Haskell/LSP/Types/Lens.hs:89)
HasScopeUri (src/Language/Haskell/LSP/Types/Lens.hs:90)
HasSection (src/Language/Haskell/LSP/Types/Lens.hs:90)
HasItems (src/Language/Haskell/LSP/Types/Lens.hs:91)
HasRange (src/Language/Haskell/LSP/Types/Lens.hs:93)
HasRangeLength (src/Language/Haskell/LSP/Types/Lens.hs:93)
HasText (src/Language/Haskell/LSP/Types/Lens.hs:93)
HasContentChanges (src/Language/Haskell/LSP/Types/Lens.hs:94)
HasSyncKind (src/Language/Haskell/LSP/Types/Lens.hs:95)
HasReason (src/Language/Haskell/LSP/Types/Lens.hs:96)
HasUri (src/Language/Haskell/LSP/Types/Lens.hs:99)
HasXtype (src/Language/Haskell/LSP/Types/Lens.hs:99)
HasChanges (src/Language/Haskell/LSP/Types/Lens.hs:100)
HasDiagnostics (src/Language/Haskell/LSP/Types/Lens.hs:101)
HasLanguage (src/Language/Haskell/LSP/Types/Lens.hs:102)
HasValue (src/Language/Haskell/LSP/Types/Lens.hs:102)
HasContents (src/Language/Haskell/LSP/Types/Lens.hs:103)
HasDocumentation (src/Language/Haskell/LSP/Types/Lens.hs:104)
HasLabel (src/Language/Haskell/LSP/Types/Lens.hs:104)
HasParameters (src/Language/Haskell/LSP/Types/Lens.hs:105)
HasActiveParameter (src/Language/Haskell/LSP/Types/Lens.hs:106)
HasActiveSignature (src/Language/Haskell/LSP/Types/Lens.hs:106)
HasSignatures (src/Language/Haskell/LSP/Types/Lens.hs:106)
HasIncludeDeclaration (src/Language/Haskell/LSP/Types/Lens.hs:108)
HasContext (src/Language/Haskell/LSP/Types/Lens.hs:109)
HasPosition (src/Language/Haskell/LSP/Types/Lens.hs:109)
HasWorkDoneToken (src/Language/Haskell/LSP/Types/Lens.hs:109)
HasQuery (src/Language/Haskell/LSP/Types/Lens.hs:111)
HasCommand (src/Language/Haskell/LSP/Types/Lens.hs:113)
HasXdata (src/Language/Haskell/LSP/Types/Lens.hs:113)
HasTarget (src/Language/Haskell/LSP/Types/Lens.hs:116)
HasInsertSpaces (src/Language/Haskell/LSP/Types/Lens.hs:117)
HasTabSize (src/Language/Haskell/LSP/Types/Lens.hs:117)
HasOptions (src/Language/Haskell/LSP/Types/Lens.hs:118)
HasCh (src/Language/Haskell/LSP/Types/Lens.hs:120)
HasNewName (src/Language/Haskell/LSP/Types/Lens.hs:121)
HasArguments (src/Language/Haskell/LSP/Types/Lens.hs:122)
HasEdit (src/Language/Haskell/LSP/Types/Lens.hs:124)
HasApplied (src/Language/Haskell/LSP/Types/Lens.hs:125)
HasParams (src/Language/Haskell/LSP/Types/Lens.hs:127)
HasCharacter (src/Language/Haskell/LSP/Types/Lens.hs:132)
HasLine (src/Language/Haskell/LSP/Types/Lens.hs:132)
HasEnd (src/Language/Haskell/LSP/Types/Lens.hs:133)
HasStart (src/Language/Haskell/LSP/Types/Lens.hs:133)
HasAdditionalTextEdits (src/Language/Haskell/LSP/Types/Lens.hs:137)
HasCommitCharacters (src/Language/Haskell/LSP/Types/Lens.hs:137)
HasDeprecated (src/Language/Haskell/LSP/Types/Lens.hs:137)
HasDetail (src/Language/Haskell/LSP/Types/Lens.hs:137)
HasFilterText (src/Language/Haskell/LSP/Types/Lens.hs:137)
HasInsertText (src/Language/Haskell/LSP/Types/Lens.hs:137)
HasInsertTextFormat (src/Language/Haskell/LSP/Types/Lens.hs:137)
HasPreselect (src/Language/Haskell/LSP/Types/Lens.hs:137)
HasSortText (src/Language/Haskell/LSP/Types/Lens.hs:137)
HasTags (src/Language/Haskell/LSP/Types/Lens.hs:137)
HasTextEdit (src/Language/Haskell/LSP/Types/Lens.hs:137)
HasTriggerCharacter (src/Language/Haskell/LSP/Types/Lens.hs:138)
HasTriggerKind (src/Language/Haskell/LSP/Types/Lens.hs:138)
HasIsIncomplete (src/Language/Haskell/LSP/Types/Lens.hs:139)
HasTitle (src/Language/Haskell/LSP/Types/Lens.hs:146)
HasPattern (src/Language/Haskell/LSP/Types/Lens.hs:149)
HasScheme (src/Language/Haskell/LSP/Types/Lens.hs:149)
HasNewText (src/Language/Haskell/LSP/Types/Lens.hs:152)
HasVersion (src/Language/Haskell/LSP/Types/Lens.hs:153)
HasEdits (src/Language/Haskell/LSP/Types/Lens.hs:154)
HasName (src/Language/Haskell/LSP/Types/Lens.hs:158)
HasAdded (src/Language/Haskell/LSP/Types/Lens.hs:159)
HasRemoved (src/Language/Haskell/LSP/Types/Lens.hs:159)
HasEvent (src/Language/Haskell/LSP/Types/Lens.hs:160)
HasJsonrpc (src/Language/Haskell/LSP/Types/Lens.hs:163)
HasCode (src/Language/Haskell/LSP/Types/Lens.hs:164)
HasMessage (src/Language/Haskell/LSP/Types/Lens.hs:164)
HasResult (src/Language/Haskell/LSP/Types/Lens.hs:165)
HasLanguageId (src/Language/Haskell/LSP/Types/Lens.hs:170)
HasSeverity (src/Language/Haskell/LSP/Types/Lens.hs:178)
HasSource (src/Language/Haskell/LSP/Types/Lens.hs:178)
HasLocation (src/Language/Haskell/LSP/Types/Lens.hs:179)
HasChildren (src/Language/Haskell/LSP/Types/Lens.hs:183)
HasSelectionRange (src/Language/Haskell/LSP/Types/Lens.hs:183)
HasContainerName (src/Language/Haskell/LSP/Types/Lens.hs:184)
HasAlpha (src/Language/Haskell/LSP/Types/Lens.hs:187)
HasBlue (src/Language/Haskell/LSP/Types/Lens.hs:187)
HasGreen (src/Language/Haskell/LSP/Types/Lens.hs:187)
HasRed (src/Language/Haskell/LSP/Types/Lens.hs:187)
HasColor (src/Language/Haskell/LSP/Types/Lens.hs:188)
HasEndCharacter (src/Language/Haskell/LSP/Types/Lens.hs:194)
HasEndLine (src/Language/Haskell/LSP/Types/Lens.hs:194)
HasStartCharacter (src/Language/Haskell/LSP/Types/Lens.hs:194)
HasStartLine (src/Language/Haskell/LSP/Types/Lens.hs:194)
HasActions (src/Language/Haskell/LSP/Types/Lens.hs:200)
HasToken (src/Language/Haskell/LSP/Types/Lens.hs:202)
HasCancellable (src/Language/Haskell/LSP/Types/Lens.hs:203)
HasPercentage (src/Language/Haskell/LSP/Types/Lens.hs:203)
12% ( 35 /277) in 'Language.Haskell.LSP.Types'
Missing documentation for:
Module header
Trace (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:97)
InitializeParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:113)
InitializeError (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:151)
TextDocumentSyncKind (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:184)
CompletionOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:230)
SignatureHelpOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:265)
CodeLensOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:294)
CodeActionOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:317)
DocumentOnTypeFormattingOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:341)
DocumentLinkOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:365)
RenameOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:389)
ExecuteCommandOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:415)
SaveOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:437)
TextDocumentSyncOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:475)
GotoOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:644)
ColorOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:659)
FoldingRangeOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:674)
WorkspaceFolderChangeNotifications (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:689)
WorkspaceFolderOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:695)
WorkspaceOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:711)
InitializeResponseCapabilitiesInner (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:722)
InitializeResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:799)
InitializeRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:801)
InitializedParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:849)
InitializedNotification (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:861)
ShutdownRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:887)
ShutdownResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:888)
ExitNotification (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:914)
TelemetryNotification (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:932)
CustomClientNotification (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:934)
CustomServerNotification (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:935)
CustomClientRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:937)
CustomServerRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:938)
CustomResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:940)
Registration (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:987)
RegistrationParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1002)
RegisterCapabilityResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1012)
TextDocumentRegistrationOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1029)
Unregistration (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1074)
UnregistrationParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1086)
UnregisterCapabilityRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1093)
UnregisterCapabilityResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1095)
DidChangeWatchedFilesRegistrationOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1148)
FileSystemWatcher (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1153)
WatchKind (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1159)
DidChangeConfigurationParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1209)
DidChangeConfigurationNotification (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1218)
ConfigurationItem (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1269)
ConfigurationParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1277)
ConfigurationRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1284)
ConfigurationResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1285)
DidOpenTextDocumentParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1313)
DidOpenTextDocumentNotification (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1320)
TextDocumentContentChangeEvent (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1372)
DidChangeTextDocumentParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1383)
DidChangeTextDocumentNotification (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1391)
TextDocumentChangeRegistrationOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1410)
TextDocumentSaveReason (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1473)
WillSaveTextDocumentParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1492)
WillSaveTextDocumentNotification (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1500)
WillSaveWaitUntilTextDocumentRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1529)
WillSaveWaitUntilTextDocumentResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1530)
DidSaveTextDocumentParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1551)
DidSaveTextDocumentNotification (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1558)
DidCloseTextDocumentParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1588)
DidCloseTextDocumentNotification (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1596)
FileChangeType (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1652)
FileEvent (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1671)
DidChangeWatchedFilesParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1679)
DidChangeWatchedFilesNotification (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1687)
PublishDiagnosticsParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1716)
PublishDiagnosticsNotification (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1725)
ParameterInformation (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1818)
SignatureInformation (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1828)
SignatureHelp (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1837)
SignatureHelpRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1846)
SignatureHelpResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1847)
SignatureHelpRegistrationOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1864)
LocationResponseParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1900)
DefinitionRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1911)
DefinitionResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1912)
TypeDefinitionRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1933)
TypeDefinitionResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1934)
ImplementationRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1956)
ImplementationResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1957)
ReferenceContext (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:1997)
ReferenceParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2005)
ReferencesRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2016)
ReferencesResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2017)
DocumentHighlightKind (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2091)
DocumentHighlight (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2107)
DocumentHighlightRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2115)
DocumentHighlightsResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2116)
WorkspaceSymbolParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2149)
WorkspaceSymbolRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2157)
WorkspaceSymbolsResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2158)
CodeLensParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2214)
CodeLens (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2225)
CodeLensRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2235)
CodeLensResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2236)
CodeLensRegistrationOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2250)
CodeLensResolveRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2281)
CodeLensResolveResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2282)
DocumentLinkParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2337)
DocumentLink (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2345)
DocumentLinkRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2353)
DocumentLinkResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2354)
DocumentLinkResolveRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2377)
DocumentLinkResolveResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2378)
FormattingOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2436)
DocumentFormattingParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2445)
DocumentFormattingRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2454)
DocumentFormattingResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2455)
DocumentRangeFormattingParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2496)
DocumentRangeFormattingRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2506)
DocumentRangeFormattingResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2507)
DocumentOnTypeFormattingParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2565)
DocumentOnTypeFormattingRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2575)
DocumentOnTypeFormattingResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2576)
DocumentOnTypeFormattingRegistrationOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2578)
RenameParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2628)
RenameRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2641)
RenameResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2642)
RangeWithPlaceholder (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2672)
RangeOrRangeWithPlaceholder (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2681)
PrepareRenameRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2686)
PrepareRenameResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2687)
ExecuteCommandParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2740)
ExecuteCommandRequest (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2749)
ExecuteCommandResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2750)
ExecuteCommandRegistrationOptions (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2752)
ApplyWorkspaceEditParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2795)
ApplyWorkspaceEditResponseBody (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2802)
ApplyWorkspaceEditResponse (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2811)
TraceParams (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2817)
TraceNotification (src/Language/Haskell/LSP/Types/DataTypesJSON.hs:2825)
CodeActionKind (src/Language/Haskell/LSP/Types/CodeAction.hs:214)
CodeActionContext (src/Language/Haskell/LSP/Types/CodeAction.hs:245)
CodeActionParams (src/Language/Haskell/LSP/Types/CodeAction.hs:254)
CodeAction (src/Language/Haskell/LSP/Types/CodeAction.hs:264)
CAResult (src/Language/Haskell/LSP/Types/CodeAction.hs:282)
CodeActionRequest (src/Language/Haskell/LSP/Types/CodeAction.hs:293)
CodeActionResponse (src/Language/Haskell/LSP/Types/CodeAction.hs:294)
ColorInformation (src/Language/Haskell/LSP/Types/Color.hs:92)
DocumentColorParams (src/Language/Haskell/LSP/Types/Color.hs:100)
DocumentColorRequest (src/Language/Haskell/LSP/Types/Color.hs:108)
DocumentColorResponse (src/Language/Haskell/LSP/Types/Color.hs:110)
ColorPresentationParams (src/Language/Haskell/LSP/Types/Color.hs:169)
ColorPresentation (src/Language/Haskell/LSP/Types/Color.hs:183)
ColorPresentationRequest (src/Language/Haskell/LSP/Types/Color.hs:201)
ColorPresentationResponse (src/Language/Haskell/LSP/Types/Color.hs:203)
Command (src/Language/Haskell/LSP/Types/Command.hs:38)
CompletionItemKind (src/Language/Haskell/LSP/Types/Completion.hs:23)
CompletionItemTag (src/Language/Haskell/LSP/Types/Completion.hs:105)
InsertTextFormat (src/Language/Haskell/LSP/Types/Completion.hs:305)
CompletionDoc (src/Language/Haskell/LSP/Types/Completion.hs:327)
CompletionItem (src/Language/Haskell/LSP/Types/Completion.hs:338)
CompletionListType (src/Language/Haskell/LSP/Types/Completion.hs:396)
CompletionResponseResult (src/Language/Haskell/LSP/Types/Completion.hs:404)
CompletionContext (src/Language/Haskell/LSP/Types/Completion.hs:437)
CompletionParams (src/Language/Haskell/LSP/Types/Completion.hs:448)
CompletionResponse (src/Language/Haskell/LSP/Types/Completion.hs:461)
CompletionRequest (src/Language/Haskell/LSP/Types/Completion.hs:462)
CompletionRegistrationOptions (src/Language/Haskell/LSP/Types/Completion.hs:484)
CompletionItemResolveRequest (src/Language/Haskell/LSP/Types/Completion.hs:513)
CompletionItemResolveResponse (src/Language/Haskell/LSP/Types/Completion.hs:514)
DiagnosticSeverity (src/Language/Haskell/LSP/Types/Diagnostic.hs:40)
DiagnosticTag (src/Language/Haskell/LSP/Types/Diagnostic.hs:81)
DiagnosticRelatedInformation (src/Language/Haskell/LSP/Types/Diagnostic.hs:124)
NumberOrString (src/Language/Haskell/LSP/Types/Diagnostic.hs:186)
DiagnosticSource (src/Language/Haskell/LSP/Types/Diagnostic.hs:195)
Diagnostic (src/Language/Haskell/LSP/Types/Diagnostic.hs:196)
DocumentFilter (src/Language/Haskell/LSP/Types/DocumentFilter.hs:41)
DocumentSelector (src/Language/Haskell/LSP/Types/DocumentFilter.hs:55)
FoldingRangeParams (src/Language/Haskell/LSP/Types/FoldingRange.hs:14)
FoldingRangeRequest (src/Language/Haskell/LSP/Types/FoldingRange.hs:71)
FoldingRangeResponse (src/Language/Haskell/LSP/Types/FoldingRange.hs:72)
LanguageString (src/Language/Haskell/LSP/Types/Hover.hs:43)
MarkedString (src/Language/Haskell/LSP/Types/Hover.hs:52)
HoverContents (src/Language/Haskell/LSP/Types/Hover.hs:106)
toMarkupContent (src/Language/Haskell/LSP/Types/Hover.hs:136)
Hover (src/Language/Haskell/LSP/Types/Hover.hs:142)
HoverRequest (src/Language/Haskell/LSP/Types/Hover.hs:150)
HoverResponse (src/Language/Haskell/LSP/Types/Hover.hs:151)
Position (src/Language/Haskell/LSP/Types/Location.hs:41)
Range (src/Language/Haskell/LSP/Types/Location.hs:71)
Location (src/Language/Haskell/LSP/Types/Location.hs:92)
ClientMethod (src/Language/Haskell/LSP/Types/Message.hs:72)
ServerMethod (src/Language/Haskell/LSP/Types/Message.hs:214)
RequestMessage (src/Language/Haskell/LSP/Types/Message.hs:279)
ErrorCode (src/Language/Haskell/LSP/Types/Message.hs:327)
ResponseError (src/Language/Haskell/LSP/Types/Message.hs:392)
ResponseMessage (src/Language/Haskell/LSP/Types/Message.hs:425)
ErrorResponse (src/Language/Haskell/LSP/Types/Message.hs:456)
BareResponseMessage (src/Language/Haskell/LSP/Types/Message.hs:460)
NotificationMessage (src/Language/Haskell/LSP/Types/Message.hs:474)
CancelParams (src/Language/Haskell/LSP/Types/Message.hs:511)
CancelNotification (src/Language/Haskell/LSP/Types/Message.hs:518)
CancelNotificationServer (src/Language/Haskell/LSP/Types/Message.hs:519)
DocumentSymbolParams (src/Language/Haskell/LSP/Types/Symbol.hs:103)
SymbolKind (src/Language/Haskell/LSP/Types/Symbol.hs:113)
DSResult (src/Language/Haskell/LSP/Types/Symbol.hs:260)
DocumentSymbolRequest (src/Language/Haskell/LSP/Types/Symbol.hs:272)
DocumentSymbolsResponse (src/Language/Haskell/LSP/Types/Symbol.hs:273)
TextDocumentIdentifier (src/Language/Haskell/LSP/Types/TextDocument.hs:28)
TextDocumentItem (src/Language/Haskell/LSP/Types/TextDocument.hs:66)
TextDocumentPositionParams (src/Language/Haskell/LSP/Types/TextDocument.hs:98)
Uri (src/Language/Haskell/LSP/Types/Uri.hs:41)
uriToFilePath (src/Language/Haskell/LSP/Types/Uri.hs:92)
filePathToUri (src/Language/Haskell/LSP/Types/Uri.hs:120)
NormalizedUri (src/Language/Haskell/LSP/Types/Uri.hs:48)
toNormalizedUri (src/Language/Haskell/LSP/Types/Uri.hs:75)
fromNormalizedUri (src/Language/Haskell/LSP/Types/Uri.hs:81)
toNormalizedFilePath (src/Language/Haskell/LSP/Types/Uri.hs:181)
fromNormalizedFilePath (src/Language/Haskell/LSP/Types/Uri.hs:188)
normalizedFilePathToUri (src/Language/Haskell/LSP/Types/Uri.hs:191)
uriToNormalizedFilePath (src/Language/Haskell/LSP/Types/Uri.hs:194)
platformAwareUriToFilePath (src/Language/Haskell/LSP/Types/Uri.hs:96)
platformAwareFilePathToUri (src/Language/Haskell/LSP/Types/Uri.hs:124)
MessageType (src/Language/Haskell/LSP/Types/Window.hs:63)
ShowMessageParams (src/Language/Haskell/LSP/Types/Window.hs:85)
ShowMessageNotification (src/Language/Haskell/LSP/Types/Window.hs:93)
MessageActionItem (src/Language/Haskell/LSP/Types/Window.hs:143)
ShowMessageRequestParams (src/Language/Haskell/LSP/Types/Window.hs:151)
ShowMessageRequest (src/Language/Haskell/LSP/Types/Window.hs:160)
ShowMessageResponse (src/Language/Haskell/LSP/Types/Window.hs:161)
LogMessageParams (src/Language/Haskell/LSP/Types/Window.hs:192)
LogMessageNotification (src/Language/Haskell/LSP/Types/Window.hs:201)
WorkDoneProgressCreateParams (src/Language/Haskell/LSP/Types/Window.hs:475)
WorkDoneProgressCreateRequest (src/Language/Haskell/LSP/Types/Window.hs:482)
TextEdit (src/Language/Haskell/LSP/Types/WorkspaceEdit.hs:42)
TextDocumentVersion (src/Language/Haskell/LSP/Types/WorkspaceEdit.hs:69)
VersionedTextDocumentIdentifier (src/Language/Haskell/LSP/Types/WorkspaceEdit.hs:71)
TextDocumentEdit (src/Language/Haskell/LSP/Types/WorkspaceEdit.hs:106)
WorkspaceEditMap (src/Language/Haskell/LSP/Types/WorkspaceEdit.hs:144)
WorkspaceEdit (src/Language/Haskell/LSP/Types/WorkspaceEdit.hs:146)
WorkspaceFolder (src/Language/Haskell/LSP/Types/WorkspaceFolders.hs:52)
WorkspaceFoldersRequest (src/Language/Haskell/LSP/Types/WorkspaceFolders.hs:62)
WorkspaceFoldersResponse (src/Language/Haskell/LSP/Types/WorkspaceFolders.hs:63)
DidChangeWorkspaceFoldersParams (src/Language/Haskell/LSP/Types/WorkspaceFolders.hs:120)
DidChangeWorkspaceFoldersNotification (src/Language/Haskell/LSP/Types/WorkspaceFolders.hs:128)
haddock: panic! (the 'impossible' happened)
(GHC version 8.10.3:
ModOrigin: hidden module redefined
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```
## Expected behavior
I'd like error message to hint at module name, say
```
haddock: panic! (the 'impossible' happened)
(GHC version 8.10.3:
ModOrigin: hidden module <$MODNAME> redefined
```
## Environment
* GHC version used: 8.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/19286ghc and ghci don't read the default package environment file on Windows2021-12-09T20:47:10Zdanidiazghc and ghci don't read the default package environment file on Windows## Summary
According to the [package environments section](https://downloads.haskell.org/ghc/latest/docs/html/users_guide/packages.html#package-environments) of the User Guide, `ghc` and `ghci` invocations should use the `$HOME/.ghc/arc...## Summary
According to the [package environments section](https://downloads.haskell.org/ghc/latest/docs/html/users_guide/packages.html#package-environments) of the User Guide, `ghc` and `ghci` invocations should use the `$HOME/.ghc/arch-os-version/environments/default` package environment file if it exists and no specific options have been given to the contrary.
This works correctly on Linux, but the file is not being found on Windows.
On my machine, the default package environment is located at `C:\Users\myuser\.ghc\x86_64-mingw32-8.10.3\environments\default`.
## Steps to reproduce
Create a package environment file in the default location. The simplest way is to install a library with [`cabal install --lib`](https://cabal.readthedocs.io/en/3.4/cabal-commands.html#cabal-v2-install):
`cabal install --lib sop-core`
Then, in an empty folder, start `ghci`, then try to `import Data.SOP.NP`.
Also create a `Main.hs` which imports `Data.SOP.NP` and try to compile with `ghc`.
## Expected behavior
Neither `ghci` nor `ghc` should complain about not finding the module.
`ghci` should show a `Loaded package environment from...` message when starting up.
## Environment
* GHC version used: 8.10.3
* Operating System: Windows 10https://gitlab.haskell.org/ghc/ghc/-/issues/18070GHC 8.10's API can load interfaces with the wrong package identifier when loo...2020-08-13T22:22:56ZquasicomputationalGHC 8.10's API can load interfaces with the wrong package identifier when looking for pluginsOriginally a doctest bug report: https://github.com/sol/doctest/issues/264
I inlined the relevant code from doctest into the provided reproducer, producing [this reduced reproducer](https://github.com/quasicomputational/test-doctest). R...Originally a doctest bug report: https://github.com/sol/doctest/issues/264
I inlined the relevant code from doctest into the provided reproducer, producing [this reduced reproducer](https://github.com/quasicomputational/test-doctest). Run with `./run-test.sh`.
On my machine, I get an error that looks like this:
```
test-doctest: Bad interface file: [..]/dist-newstyle/build/x86_64-linux/ghc-8.10.1/dummy-plugin-0.1.0.0/build/DummyDefs.hi
Something is amiss; requested module dummy-plugin-0.1.0.0:DummyDefs differs from name found in the interface file ghc-compact-0.1.0.0:DummyDefs (if these names look the same, try again with -dppr-debug)
```
Where does that `ghc-compact` come from? I have no idea. Even more puzzlingly, if I turn up GHC's verbosity, that turns into `process`!
[`test-doctest.hs`](https://github.com/quasicomputational/test-doctest/blob/master/test-doctest.hs) is the (now misleadingly-named) code driving GHC, and as far as I can tell it's not doing anything exotic or bizarre.
[`Haddock.Interface`](https://github.com/haskell/haddock/blob/8c6532636e6bd572455dfcf0b0d6e05f7033d110/haddock-api/src/Haddock/Interface.hs) is the roughly corresponding code in Haddock, which seems to mostly do the same thing - and yet Haddock works and doctest doesn't. I have no idea what the difference is, except that it might be something to do with order-sensitivity in how modules are loaded.
The error doesn't happen on GHC 8.8. I couldn't find anything in the release notes warning me about any changes here, so this is a regression.https://gitlab.haskell.org/ghc/ghc/-/issues/18025INSTALL instructions of linux bindist says "make install" while it should be ...2020-04-08T23:06:50ZjwaldmannINSTALL instructions of linux bindist says "make install" while it should be "sudo make install"INSTALL of https://downloads.haskell.org/~ghc/8.8.3/ghc-8.8.3-x86_64-deb9-linux.tar.xz (and probably others) says
```
The default installation directory is /usr/local
...
Now run:
make install
```
This will fail, as "sudo make instal...INSTALL of https://downloads.haskell.org/~ghc/8.8.3/ghc-8.8.3-x86_64-deb9-linux.tar.xz (and probably others) says
```
The default installation directory is /usr/local
...
Now run:
make install
```
This will fail, as "sudo make install" is needed.https://gitlab.haskell.org/ghc/ghc/-/issues/17716Installed help files have broken hyperlink to Users Guide / local Users Guid...2020-01-20T21:34:37ZfreenInstalled help files have broken hyperlink to Users Guide / local Users Guide currently installed to wrong location## Summary
Accessing help from WinGHCi by pressing F1 or via the menu (Help->GHC Documentation) brings up the locally installed "GHC Documentation" page located at:
(Install Path)/doc/html/index.html
On this page there are hyperli...## Summary
Accessing help from WinGHCi by pressing F1 or via the menu (Help->GHC Documentation) brings up the locally installed "GHC Documentation" page located at:
(Install Path)/doc/html/index.html
On this page there are hyperlinks to:
* The Users Guide (href="users_guide/index.html")
* Libraries (href="libraries/index.html")
* GHC API (href="libraries/ghc-8.6.5/index.html")
The first link is broken, but the second and third links work.
The html help files are respectively located in:
* "(Install Path)/doc/users_guide"
* "(Install Path)/doc/html/libraries/" &
* "(Install Path)/doc/html/libraries/ghc-8.6.5/"
suggesting that the users_guide directory is not currently in the correct location.
## Proposed improvements or changes
Move the install location of the users_guide directory so it is in the doc/html/ directory. Doing this manually appears to resolve the issue.
## Environment
* GHC version used (if appropriate):
Win64 WinGHCi/Haskell Platform 8.6.5https://gitlab.haskell.org/ghc/ghc/-/issues/17191Split configure script2024-02-09T21:09:44ZJohn EricsonSplit configure script## Motivation
We're getting pretty close to being done making GHC multi-target. One consequence of this is that GHC itself won't depend on the vast majority of the `@vars@` from configure. Only src-determined things like `@ProjectVersio...## Motivation
We're getting pretty close to being done making GHC multi-target. One consequence of this is that GHC itself won't depend on the vast majority of the `@vars@` from configure. Only src-determined things like `@ProjectVersionMunged@`, `@LlvmVersion@`, etc. are still needed project-wide.
What I propose then is we strip down the root `configure.ac` to just substitute those platform-agnostic variables with no dynamic checks, and push the vast majority of the configure checks into package-specific configure scripts rts, inter-gmp, and base. The `settings` file does depend on a number of configure checks, but it can be either an extra file installed by the `rts`, which makes sense is it basically is saying how to produce Haskell which works with a given RTS, or get it's own configure script. As usual, the `m4` directory means we an share as much logic as we like between these scripts.
This has a number of benefits:
0. Running top-level configure should only make changes that are "safe for sdist". E.g. we can put all the versions in the cabal files and then sdist each cabal package. C.f. !5965.
1. Prevents regressions with multi-target: Compiler doesn't know about the target platform by construction, so it cannot be biased towards one or another.
2. Slightly more parallelism: we can immediately start building the compiler.
3. Better incremental builds: Changing configure results will no longer invalidate the stage 0 compiler build via `ghcautoconf.h`. More broadly each package only sees the options it cares about, so smaller incremental benefits for the other libs.
5. One step closer to `cabal build ghc` for a stage 0 compiler. Running the meta-configure is trivial preprocessor step that also could be done in `./boot` instead of autoconf as follow up work. Then the only thing blocking the cabal-built compilers is code gen executables `genprimmops`. But we have `build-tool-depends` already to hack something up, and longer term I hope https://github.com/ghc-proposals/ghc-proposals/pull/243 means it can all become TH.
I'll try to avoid controversy by *not* including getting rid of autoconf in the above list :). My view is this split delivers most of the benefit of that, and right now `configure.ac` is too big and monolithic to assess how much we depend on autoconf and where. With this change any renewed talk on purging autoconf will be a better evidence-based discussion.
## Things that get configured today
Good to keep in mind.
- `ghcautoconf.h`, from `AC_DEFINE`, via `mk/config.h`
- `settings` files per stage, originally directly via type level configure, now indirectly via make/hadrian
- Build system config files, from `AC_SUBST`:
- `hadrian/cfg/system.config`
- `mk/config.mk`
## Roadmap
### Prep Make build system
It turns out there was a few things to do with the make build system to make it better cope with the RTS having a configure script, and generally anticipate the goals here.
- [x] !6816
- [x] !6821
- [x] !6817
- [x] !6819
- [x] !6869
- [x] !6864
- [x] !6908
- [x] !6833 Make: Do not generate ghc.* headers in stage
- [x] !6966
- [x] !6977
- [x] !6978
- [x] !6989
### Prep Hadrian changes
- [x] !6953 Hadrian: bring up to date with latest make improvements
- [x] !6978
### Prep Autoconf changes
- [x] !6828 modularize platform detection.
- [x] !6836 Separate some `AC_SUBST` / `AC_DEFINE`
- [x] !6927 Factor out unregisterised and tables next to code m4 macros
- [x] !6931 Factor out more m4 macros
- [x] !6964
### Other prep
- [x] !6216 Move `/includes` to `/rts/include`, sort per package better
- [x] !6839 Avoid GHC_STAGE and other include bits
- [x] !6791 / !6920 Compiler is target agnostic!
- [x] !6963 Generate ghcversion.h with the top-level configure
- [x] !6987
- [x] !7100
- [x] !9627 Remove hack for building RTS that gets in the way of `build-type: Simple`.
### Intro RTS Configure script
A beachhead!
- [x] !6822 (optional intermediate step) do blank RTS configure script before moving anything over.
- [x] !9760 Bump Cabal so configure script can detect cabal flags.
- [x] !9756 Move extern symbols logic
### Headers generated RTS side.
Hadrian can still tell RTS what the configuration is (the RTS configure script wont't yet decide for itself), but `ghcautoconf.h` and `ghcplatform.h` are made in the RTS configure script. `mk/config.h` can be deleted.
### Rest of RTS-oriented configure logic.
The RTS is able to figure out its configuration without relying on correctly-set manual Cabal flags.
Perhaps the RTS will contain some settings info that Hadrian reads (c.f. #22686) i.e. it could be a source of truth.
1. [x] !11311
2. [x] !11319
3. [x] !11317
4. [x] !11318
4. [x] !11322
5. [x] !6803
### Slim down Cabal Flags for RTS
With the logic from before moved into the RTS configure script, there is often no need to make decision from the outside --- just let the RTS configure script make its own private choice.
We can do that and get rid of a bunch of Hadrian logic.
- [x] !9269 / `wip/rts-configure-scrap-cabal-flags`
### Get rid of rest of configure script
See
- #24008
- #23966
### `genapply` shouldn't take RTS headers at compile time
If the RTS is built standalone, there it will be annoying to *build* genapply at *RTS configure* time. We should do something different -- like make genapply take the info at runtime so we can use a prebuilt genapply.
### Create configure script for settings file.
Many decisions however need to effect both RTS and settings file. At a minimum, we can share `m4` logic between projects, but we may also want to make (part of) the settings file during the RTS build.
Some settings effectively indicate choices where the RTS and GHC must agree, so deciding twice and hoping the system-snooping is deterministic is sketch. Other settings like what tools to use are naturally independent.
Note it is precisely second sort that the bindist will configure today.
### Possible prepare stage-wide configure more like status-quo-ante for hadrian/make
While it's important than components can be configured separately to untangle our current mess, hadrian/make might continue to want to make some settings across projects. Concretely, *something* need to fill in their settings input files, `hadrian/cfg/system.config`, and `mk/config.mk`.
We can have our cake and eat it too by keeping enough logic in `m4` files to create a "stage-wide" configure script.
(Remember, per https://gitlab.haskell.org/ghc/ghc/-/wikis/cross-compilation/roadmap bootstrapping is an infinite tree to explore, not a single chain, let alone a finite 3 stage chain! So stage-wide config files vs one master config files makes much more sense as input to Hadrian/Make.)
Additionally, we should enhance the autoconf macros to ensure every decision solved by the "outer" configure is not re-decided by the per-package configures. That means adding enough configure flags so the decisions can be "told" by make/hadrian to RTS/base/unix/whatever.
This last step might sound like it is undermining the whole project: what's the point of moving all the logic to per-package configure scripts if we are just going to centrally configure the decisions anyways?! Remember, only make/hadrian parameters that are either inspected/eliminated by the outer build system or "aliased" to multiple packages need be in the outer configure. The vast majority of stuff is just needed by on package (usually the RTS), or was `AC_DEFINED` and already bypasses the output build system going straight from autoconf to the headers. All such things need never be configured from the stage-wide configure script, and should purely be per-stage.
Also, downstream packaging like Haskell.nix or Nixpkgs will probably stop using Make/Hadrian, and thus bypass any stage-wide configuring, but will use the per-package configures. In general "whole compilers" should be thought of as mini-distros and not single packages, and thus our Make/Hadrian are more like package managers / multiple monorepo build systems (like the original BSD monorepo).
CC @angerman @alp @bgamari @hvr @nomeata @snowleopard @hsyl20 @nrnrnrhttps://gitlab.haskell.org/ghc/ghc/-/issues/16554Mixing `-package-env` and explicit package flags doesn't seem to work.2019-04-12T16:14:28ZOleg GrenrusMixing `-package-env` and explicit package flags doesn't seem to work.# Summary
Mixing `-package-env` and explicit package flags doesn't seem to work.
# Steps to reproduce
```
% ghci -package-env=default -hide-all-packages -clear-package-db
GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help
L...# Summary
Mixing `-package-env` and explicit package flags doesn't seem to work.
# Steps to reproduce
```
% ghci -package-env=default -hide-all-packages -clear-package-db
GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help
Loaded package environment from /home/ogre/.ghc/x86_64-linux-8.4.4/environments/default
Loaded GHCi configuration from /home/ogre/.ghci
```
# Expected behavior
I'd expect either empty package environment, or at least a warning that latter package database flags are ignored.
# Environment
* GHC version used: 8.4.4, 8.6.44
Optional:
* Operating System: Linux
* System Architecture: x86_64https://gitlab.haskell.org/ghc/ghc/-/issues/16318Explicitly passing -package-env causes "Loaded package environment from .ghc....2020-08-10T14:07:24ZRyan ScottExplicitly passing -package-env causes "Loaded package environment from .ghc.environment" message to be printed twice```
$ /opt/ghc/8.6.3/bin/ghc -package-env .ghc.environment.x86_64-linux-8.6.3 -e "putStrLn \"Hello\""
Loaded package environment from .ghc.environment.x86_64-linux-8.6.3
Loaded package environment from .ghc.environment.x86_64-linux-8.6.3...```
$ /opt/ghc/8.6.3/bin/ghc -package-env .ghc.environment.x86_64-linux-8.6.3 -e "putStrLn \"Hello\""
Loaded package environment from .ghc.environment.x86_64-linux-8.6.3
Loaded package environment from .ghc.environment.x86_64-linux-8.6.3
Hello
```
This is a regression from GHC 8.4.4:
```
$ /opt/ghc/8.4.4/bin/ghc -package-env .ghc.environment.x86_64-linux-8.4.4 -e "putStrLn \"Hello\""
Loaded package environment from .ghc.environment.x86_64-linux-8.4.4
Hello
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Explicitly passing -package-env causes \"Loaded package environment from .ghc.environment\" message to be printed twice","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["hvr"],"type":"Bug","description":"{{{\r\n$ /opt/ghc/8.6.3/bin/ghc -package-env .ghc.environment.x86_64-linux-8.6.3 -e \"putStrLn \\\"Hello\\\"\"\r\nLoaded package environment from .ghc.environment.x86_64-linux-8.6.3\r\nLoaded package environment from .ghc.environment.x86_64-linux-8.6.3\r\nHello\r\n}}}\r\n\r\nThis is a regression from GHC 8.4.4:\r\n\r\n{{{\r\n$ /opt/ghc/8.4.4/bin/ghc -package-env .ghc.environment.x86_64-linux-8.4.4 -e \"putStrLn \\\"Hello\\\"\"\r\nLoaded package environment from .ghc.environment.x86_64-linux-8.4.4\r\nHello\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Artem PelenitsynArtem Pelenitsynhttps://gitlab.haskell.org/ghc/ghc/-/issues/15328cpphs: internal error: evacuate(static): strange closure type 84402021-09-28T14:02:00Zcnmnecpphs: internal error: evacuate(static): strange closure type 8440Attempting to install Agda via Cabal fails.
I've installed cpphs through Cabal and `~/Library/Haskell/bin` is in my path.
`~/.cabal/config` is default, but in `/Library/Frameworks/GHC.framework/Versions/8.4.3-x86_64/usr/lib/ghc-8.4.3 /...Attempting to install Agda via Cabal fails.
I've installed cpphs through Cabal and `~/Library/Haskell/bin` is in my path.
`~/.cabal/config` is default, but in `/Library/Frameworks/GHC.framework/Versions/8.4.3-x86_64/usr/lib/ghc-8.4.3 /settings` I have changed only `("C compiler supports -no-pie","NO")` (from "YES") because that was giving me errors earlier.
The log states: "Please report this as a GHC bug..." so here I am :\]
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"cpphs: internal error: evacuate(static): strange closure type 8440","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["cabal,","closure","cpphs,","strange"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Attempting to install Agda via Cabal fails.\r\n\r\nI've installed cpphs through Cabal and {{{~/Library/Haskell/bin}}} is in my path.\r\n\r\n{{{~/.cabal/config}}} is default, but in {{{/Library/Frameworks/GHC.framework/Versions/8.4.3-x86_64/usr/lib/ghc-8.4.3 /settings}}} I have changed only {{{(\"C compiler supports -no-pie\",\"NO\")}}} (from \"YES\") because that was giving me errors earlier.\r\n\r\nThe log states: \"Please report this as a GHC bug...\" so here I am :]","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14182Allow full control over dyn lib names2019-07-07T18:18:06ZduncanAllow full control over dyn lib namesThis is related to:
- GHC ticket #11587
- Cabal issue https://github.com/haskell/cabal/issues/4263
- Cabal PR https://github.com/haskell/cabal/pull/4656
- Cabal PR https://github.com/haskell/cabal/pull/4426
Currently GHC hard codes the...This is related to:
- GHC ticket #11587
- Cabal issue https://github.com/haskell/cabal/issues/4263
- Cabal PR https://github.com/haskell/cabal/pull/4656
- Cabal PR https://github.com/haskell/cabal/pull/4426
Currently GHC hard codes the naming convention for shared/dynamic libraries. For example:
For `hs-libraries: HScpu-0.1.2-b25995` in the package registration, on ELF GHC uses the name `libHScpu-0.1.2-b2599-ghc8.0.1.so` (and .dynlib on OSX).
This naming convention is based on an old assumption that shared libraries would go in a shared `$libdir`, and that all that was needed to ensure uniqueness was the combination of the package id and ghc version.
This assumption is very out of date now. Different install schemes are used by different packaging tools (nix style vs classic style) and sometimes we want shared lib dirs and sometimes not, and of course we all know now that a package id is not nearly enough to ensure file names are unique.
The obvious solution is for GHC to stop making any unnecessary naming convention assumptions and allow specifying the full library name in the package registration information.
We would of course keep the remaining necessary naming convention is the `lib` prefix and `.so`/`.dynlib`/`.dll` suffix, which is the same convention used by the system linker for `-lfoo` vs `libfoo.so`.
- \*So specifically:\*\*
- Add a new `dynamic-hs-libraries` (to go along with `hs-libraries`) to the `ghc-pkg` registration information. This naming convention follows the existing `library-dirs` and `dynamic-library-dirs`.
- When this field is used then these library names will by used for dynamic linking. For backward compatibility, when this field is not supplied then the existing `-ghc8.0.1` convention is used.
While we are at it, we should do the same for the `extra-libraries` and add a `dynamic-extra-libraries`. Note that there is an existing `extra-ghci-libraries` which was added for a similar reason (though prior to ghci switching to dynamic libs by default) because in rare cases the dyn libs are just named differently from the static libs, or occasionally there are extra static vs dynamic libs. For example, `pkg-config` makes a clear distinction between static and dynamic libs (because dynamic libs only need direct deps whereas static needs the full transitive closure).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Allow full control over dyn lib names","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This is related to: \r\n\r\n * GHC ticket #11587\r\n * Cabal issue https://github.com/haskell/cabal/issues/4263\r\n * Cabal PR https://github.com/haskell/cabal/pull/4656\r\n * Cabal PR https://github.com/haskell/cabal/pull/4426\r\n\r\nCurrently GHC hard codes the naming convention for shared/dynamic libraries. For example:\r\n\r\nFor `hs-libraries: HScpu-0.1.2-b25995` in the package registration, on ELF GHC uses the name `libHScpu-0.1.2-b2599-ghc8.0.1.so` (and .dynlib on OSX).\r\n\r\nThis naming convention is based on an old assumption that shared libraries would go in a shared `$libdir`, and that all that was needed to ensure uniqueness was the combination of the package id and ghc version.\r\n\r\nThis assumption is very out of date now. Different install schemes are used by different packaging tools (nix style vs classic style) and sometimes we want shared lib dirs and sometimes not, and of course we all know now that a package id is not nearly enough to ensure file names are unique.\r\n\r\nThe obvious solution is for GHC to stop making any unnecessary naming convention assumptions and allow specifying the full library name in the package registration information.\r\n\r\nWe would of course keep the remaining necessary naming convention is the `lib` prefix and `.so`/`.dynlib`/`.dll` suffix, which is the same convention used by the system linker for `-lfoo` vs `libfoo.so`.\r\n\r\n**So specifically:**\r\n\r\n* Add a new `dynamic-hs-libraries` (to go along with `hs-libraries`) to the `ghc-pkg` registration information. This naming convention follows the existing `library-dirs` and `dynamic-library-dirs`.\r\n\r\n* When this field is used then these library names will by used for dynamic linking. For backward compatibility, when this field is not supplied then the existing `-ghc8.0.1` convention is used.\r\n\r\nWhile we are at it, we should do the same for the `extra-libraries` and add a `dynamic-extra-libraries`. Note that there is an existing `extra-ghci-libraries` which was added for a similar reason (though prior to ghci switching to dynamic libs by default) because in rare cases the dyn libs are just named differently from the static libs, or occasionally there are extra static vs dynamic libs. For example, `pkg-config` makes a clear distinction between static and dynamic libs (because dynamic libs only need direct deps whereas static needs the full transitive closure).","type_of_failure":"OtherFailure","blocking":[]} -->