GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2021-02-23T19:54:21Zhttps://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/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/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":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13475Possible missing case in ghc-pkg2019-07-07T18:21:42ZTamar ChristinaPossible missing case in ghc-pkgI saw this while compiling
```
utils\ghc-pkg\Main.hs:761:25: Warning:
Pattern match(es) are non-exhaustive
In a case alternative: Patterns not matched: GhcPkg.DbOpenReadOnly
```
I don't know if this is indicative of a bug in th...I saw this while compiling
```
utils\ghc-pkg\Main.hs:761:25: Warning:
Pattern match(es) are non-exhaustive
In a case alternative: Patterns not matched: GhcPkg.DbOpenReadOnly
```
I don't know if this is indicative of a bug in the implementation or not?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.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":"Possible missing case in ghc-pkg","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I saw this while compiling\r\n\r\n{{{\r\nutils\\ghc-pkg\\Main.hs:761:25: Warning:\r\n Pattern match(es) are non-exhaustive\r\n In a case alternative: Patterns not matched: GhcPkg.DbOpenReadOnly\r\n}}}\r\n\r\nI don't know if this is indicative of a bug in the implementation or not?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12518Allow customizing immutable package dbs by stacking2019-07-07T18:26:16ZharendraAllow customizing immutable package dbs by stacking# Package Selection Across Multiple Package DBs
As explained by ezyang, when there are multiple package dbs, GHC chooses the packages to use in the following manner. I might have misunderstood so please correct me if I am wrong.
- If t...# Package Selection Across Multiple Package DBs
As explained by ezyang, when there are multiple package dbs, GHC chooses the packages to use in the following manner. I might have misunderstood so please correct me if I am wrong.
- If there are multiple packages with different versions the latest non-broken version is chosen.
- If the there are multiple packages with the same version the behavior is unspecified.
- If there are multiple packages with the same installed package id (shadowing) then the one which comes first in `GHC_PACKAGE_PATH` or which comes last on command line (according to `-package-db` flags) will be used.
# The Problem
The build tool `Stack` implements stacked package databases. It uses a base package database and then stacks another package database on top of it to customise it further without modifying. The behavior is such that the package db on top of the stack completely overrides the ones below. That means you choose a package from top of the stack even if the version is older.
Stack implements this by passing explicit package-ids of the packages to GHC. This scheme works well for cabal projects where we know ALL the packages used by the project in advance. But it does not work for scripts run using runghc. In that case we do not know the packages required by the script in advance and therefore cannot pass the package-ids to GHC. That means we cannot make GHC use the packages in the right way. GHC will choose the latest version even though we want it to choose a possibly older version from the top of the db stack.
# Proposed Solution
Implement a new CLI option, something like `--stacked-pkg-dbs`. If this option is used GHC will use `GHC_PACKAGE_PATH` or the `-package-db` options to specify a stack of dbs. The first db in the path or the last CLI option will be considered the top of the stack.
The default behavior of GHC is to union all databases whereas this feature is about vertically stacking them. The following stacking rules will apply:
- GHC will search a package from top to bottom and stop at the first db in which the package exists.
- If GHC is not looking for a specific version then it will stop at the first db in which ANY version is found.
- It will ignore the hidden packages when searching, but `-package <pkg>` will have the effect of unhiding all versions of `<pkg>`.
- If there are multiple versions available in the same db then usual rules of latest non-broken package will be used to select one.
- If the candidate package(s) found is broken it will not search further. When a broken package is needed in compilation it will report an error. It will not report errors in general when a broken package is encountered.
This will allow us to modify an immutable package db by stacking another db on top. Implementing this as a separate option will keep the existing behavior so as to remain backward compatible.
This has been discussed in a stack issue on github [here](https://github.com/commercialhaskell/stack/issues/1957).https://gitlab.haskell.org/ghc/ghc/-/issues/12485-package-db flags now need to be sorted by dependency order2019-07-07T18:26:24Zniteria-package-db flags now need to be sorted by dependency orderAfter 39b71e81ec1044518f065d0055676d713521e483 putting the -package-db flags in the wrong order will result in a compile error:
```
<command line>: cannot satisfy -package-id b-1-XXX:
b-1-XXX is unusable due to missing or recursive ...After 39b71e81ec1044518f065d0055676d713521e483 putting the -package-db flags in the wrong order will result in a compile error:
```
<command line>: cannot satisfy -package-id b-1-XXX:
b-1-XXX is unusable due to missing or recursive dependencies:
a-1-XXX
(use -v for more information)
```
See attached file for a repro.
It's reproduces in 8.0.1 and HEAD. Doesn't reproduce in GHC 7.10.3 or after reverting the above mentioned commit.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ezyang |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"-package-db flags now need to be sorted by dependency order","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ezyang"],"type":"Bug","description":"After 39b71e81ec1044518f065d0055676d713521e483 putting the -package-db flags in the wrong order will result in a compile error:\r\n{{{\r\n<command line>: cannot satisfy -package-id b-1-XXX:\r\n b-1-XXX is unusable due to missing or recursive dependencies:\r\n a-1-XXX\r\n (use -v for more information)\r\n}}}\r\n\r\nSee attached file for a repro.\r\n\r\nIt's reproduces in 8.0.1 and HEAD. Doesn't reproduce in GHC 7.10.3 or after reverting the above mentioned commit.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.3https://gitlab.haskell.org/ghc/ghc/-/issues/12154GHC 8.0.1 x64 Windows installer doesn't honor custom install location2019-07-07T18:27:26ZscsGHC 8.0.1 x64 Windows installer doesn't honor custom install locationThe GHC Windows installer has (thankfully!) the option for a preferred custom install location, in my case 'c:\\devel\\Haskell\\8' (beside 'c:\\devel\\Haskell\\WinHugs' etc.) However, it obstinately installs into 'c:\\Program Files\\Hask...The GHC Windows installer has (thankfully!) the option for a preferred custom install location, in my case 'c:\\devel\\Haskell\\8' (beside 'c:\\devel\\Haskell\\WinHugs' etc.) However, it obstinately installs into 'c:\\Program Files\\Haskell Platform\\yada yada...' The _uninstaller_ operates with the custom location, and the uninstallation therefore fails.
Potential triggers: disallowing the installer to muck with the environment path and registry (I set these myself, thank you very much).
Workaround: GHC is thankfully still self contained, and moving the installation to the preferred location suffices.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.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":"GHC 8.0.1 x64 Windows installer doesn't honor custom install location","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The GHC Windows installer has (thankfully!) the option for a preferred custom install location, in my case 'c:\\devel\\Haskell\\8' (beside 'c:\\devel\\Haskell\\WinHugs' etc.) However, it obstinately installs into 'c:\\Program Files\\Haskell Platform\\yada yada...' The _uninstaller_ operates with the custom location, and the uninstallation therefore fails.\r\n\r\nPotential triggers: disallowing the installer to muck with the environment path and registry (I set these myself, thank you very much).\r\n\r\nWorkaround: GHC is thankfully still self contained, and moving the installation to the preferred location suffices.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/11696Windows Install Makes Unnecessary/Incorrect PATH Changes2019-07-07T18:29:03ZAlexAndrewsWindows Install Makes Unnecessary/Incorrect PATH ChangesI installed haskell 7.10.3 (32-bit) under Windows XP SP3 into a folder on my L: drive. However, the installation process added a number of non-existent directories to my PATH variables:
User environment variable PATH:
> C:\\Documents a...I installed haskell 7.10.3 (32-bit) under Windows XP SP3 into a folder on my L: drive. However, the installation process added a number of non-existent directories to my PATH variables:
User environment variable PATH:
> C:\\Documents and Settings\\\<username\>\\Application Data\\cabal\\bin
System environment variable PATH:
> C:\\Program Files\\Haskell\\bin
If these directories need to be in the PATH variables, they should be created by the installer and, if so, since I installed haskell to my L: drive, surely these should be created on my L: drive (or the user should be prompted for their location)?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.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":"Windows Install Makes Unnecessary/Incorrect PATH Changes","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.3","keywords":["environment","install","path","variable"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I installed haskell 7.10.3 (32-bit) under Windows XP SP3 into a folder on my L: drive. However, the installation process added a number of non-existent directories to my PATH variables:\r\n\r\nUser environment variable PATH:\r\n\r\n C:\\Documents and Settings\\<username>\\Application Data\\cabal\\bin\r\n\r\nSystem environment variable PATH:\r\n\r\n C:\\Program Files\\Haskell\\bin\r\n\r\nIf these directories need to be in the PATH variables, they should be created by the installer and, if so, since I installed haskell to my L: drive, surely these should be created on my L: drive (or the user should be prompted for their location)?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/11504Can't install haskell-platform in OpenBSD2019-07-07T18:30:09ZAchifaifaCan't install haskell-platform in OpenBSDI'm trying to install the haskell platform in openbsd. This is the output I get
` Can't install freeglut-2.8.0 because of libraries
|library GL.13.0 not found
| not found anywhere
|library X11.15.1 not found
| not found anywhere
|librar...I'm trying to install the haskell platform in openbsd. This is the output I get
` Can't install freeglut-2.8.0 because of libraries
|library GL.13.0 not found
| not found anywhere
|library X11.15.1 not found
| not found anywhere
|library Xdamage.3.1 not found
| not found anywhere
|library Xext.12.0 not found
| not found anywhere
|library Xfixes.5.1 not found
| not found anywhere
|library Xi.11.1 not found
| not found anywhere
|library Xrandr.6.1 not found
| not found anywhere
|library Xrender.5.0 not found
| not found anywhere
|library Xxf86vm.5.0 not found
| not found anywhere
|library drm.3.1 not found
| not found anywhere
|library xcb.2.4 not found
| not found anywhere
Can't install hs-GLUT-2.1.2.1p11: can't resolve freeglut-2.8.0
Can't install haskell-platform-2012.4.0.0p0: can't resolve hs-GLUT-2.1.2.1p11 `
I'm installing it on a laptop without a desktop environment or X server, so I'm not sure if the problem is that I don't have a X/GL installation or if the installer can't locate some packages in the source.
I'm a total newbie to both OpenBSD and Haskell, so I know nothing that could help with this. Let me know if you need any extra information about the issue.https://gitlab.haskell.org/ghc/ghc/-/issues/11455GHC-8.0.0.20160109 runs into "Bad interface file: ... Something is amiss"2019-07-07T18:30:21ZLemmingGHC-8.0.0.20160109 runs into "Bad interface file: ... Something is amiss"When I first started testing GHC-8.0.0.20160109 I could compile a lot of packages. However, now I get the following error more and more frequently:
```
$ cabal install --with-ghc=ghc-8.0.0.20160109 --with-haddock=haddock-ghc-8.0.0.20160...When I first started testing GHC-8.0.0.20160109 I could compile a lot of packages. However, now I get the following error more and more frequently:
```
$ cabal install --with-ghc=ghc-8.0.0.20160109 --with-haddock=haddock-ghc-8.0.0.20160109 http://hackage.haskell.org/package/set-cover-0.0.8/set-cover-0.0.8.tar.gz
Downloading
http://hackage.haskell.org/package/set-cover-0.0.8/set-cover-0.0.8.tar.gz
Resolving dependencies...
Configuring enummapset-0.5.2.1...
Building enummapset-0.5.2.1...
Preprocessing library enummapset-0.5.2.1...
[1 of 5] Compiling Data.EnumSet ( Data/EnumSet.hs, dist/build/Data/EnumSet.o )
...
[4 of 5] Compiling Data.EnumMap.Lazy ( Data/EnumMap/Lazy.hs, dist/build/Data/EnumMap/Lazy.p_o )
[5 of 5] Compiling Data.EnumMap ( Data/EnumMap.hs, dist/build/Data/EnumMap.p_o )
In-place registering enummapset-0.5.2.1...
Running Haddock for enummapset-0.5.2.1...
Preprocessing library enummapset-0.5.2.1...
...
Registering enummapset-0.5.2.1...
Installed enummapset-0.5.2.1
Configuring set-cover-0.0.8...
Building set-cover-0.0.8...
Preprocessing library set-cover-0.0.8...
[ 1 of 15] Compiling Math.SetCover.Cuboid ( src/Math/SetCover/Cuboid.hs, dist/build/Math/SetCover/Cuboid.o )
[ 2 of 15] Compiling Math.SetCover.Queue ( src/Math/SetCover/Queue.hs, dist/build/Math/SetCover/Queue.o )
src/Math/SetCover/Queue.hs:3:1: error:
Bad interface file: /home/cabal/lib/x86_64-linux-ghc-8.0.0.20160109/enummapset-0.5.2.1-KxKeewRMTNa4DSa3VnUuRQ/Data/EnumMap.hi
Something is amiss; requested module enummapset-0.5.2.1@enummapset-0.5.2.1-64948c41f2d75b38829fcb75933a73f0:Data.EnumMap differs from name found in the interface file enumm_KxKeewRMTNa4DSa3VnUuRQ:Data.EnumMap
src/Math/SetCover/Queue.hs:4:1: error:
Bad interface file: /home/cabal/lib/x86_64-linux-ghc-8.0.0.20160109/enummapset-0.5.2.1-KxKeewRMTNa4DSa3VnUuRQ/Data/EnumSet.hi
Something is amiss; requested module enummapset-0.5.2.1@enummapset-0.5.2.1-64948c41f2d75b38829fcb75933a73f0:Data.EnumSet differs from name found in the interface file enumm_KxKeewRMTNa4DSa3VnUuRQ:Data.EnumSet
Failed to install set-cover-0.0.8
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1-rc1 |
| 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":"GHC-8.0.0.20160109 runs into \"Bad interface file: ... Something is amiss\"","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When I first started testing GHC-8.0.0.20160109 I could compile a lot of packages. However, now I get the following error more and more frequently:\r\n{{{\r\n$ cabal install --with-ghc=ghc-8.0.0.20160109 --with-haddock=haddock-ghc-8.0.0.20160109 http://hackage.haskell.org/package/set-cover-0.0.8/set-cover-0.0.8.tar.gz\r\nDownloading\r\nhttp://hackage.haskell.org/package/set-cover-0.0.8/set-cover-0.0.8.tar.gz\r\nResolving dependencies...\r\nConfiguring enummapset-0.5.2.1...\r\nBuilding enummapset-0.5.2.1...\r\nPreprocessing library enummapset-0.5.2.1...\r\n[1 of 5] Compiling Data.EnumSet ( Data/EnumSet.hs, dist/build/Data/EnumSet.o )\r\n...\r\n[4 of 5] Compiling Data.EnumMap.Lazy ( Data/EnumMap/Lazy.hs, dist/build/Data/EnumMap/Lazy.p_o )\r\n[5 of 5] Compiling Data.EnumMap ( Data/EnumMap.hs, dist/build/Data/EnumMap.p_o )\r\nIn-place registering enummapset-0.5.2.1...\r\nRunning Haddock for enummapset-0.5.2.1...\r\nPreprocessing library enummapset-0.5.2.1...\r\n...\r\nRegistering enummapset-0.5.2.1...\r\nInstalled enummapset-0.5.2.1\r\nConfiguring set-cover-0.0.8...\r\nBuilding set-cover-0.0.8...\r\nPreprocessing library set-cover-0.0.8...\r\n[ 1 of 15] Compiling Math.SetCover.Cuboid ( src/Math/SetCover/Cuboid.hs, dist/build/Math/SetCover/Cuboid.o )\r\n[ 2 of 15] Compiling Math.SetCover.Queue ( src/Math/SetCover/Queue.hs, dist/build/Math/SetCover/Queue.o )\r\n\r\nsrc/Math/SetCover/Queue.hs:3:1: error:\r\n Bad interface file: /home/cabal/lib/x86_64-linux-ghc-8.0.0.20160109/enummapset-0.5.2.1-KxKeewRMTNa4DSa3VnUuRQ/Data/EnumMap.hi\r\n Something is amiss; requested module enummapset-0.5.2.1@enummapset-0.5.2.1-64948c41f2d75b38829fcb75933a73f0:Data.EnumMap differs from name found in the interface file enumm_KxKeewRMTNa4DSa3VnUuRQ:Data.EnumMap\r\n\r\nsrc/Math/SetCover/Queue.hs:4:1: error:\r\n Bad interface file: /home/cabal/lib/x86_64-linux-ghc-8.0.0.20160109/enummapset-0.5.2.1-KxKeewRMTNa4DSa3VnUuRQ/Data/EnumSet.hi\r\n Something is amiss; requested module enummapset-0.5.2.1@enummapset-0.5.2.1-64948c41f2d75b38829fcb75933a73f0:Data.EnumSet differs from name found in the interface file enumm_KxKeewRMTNa4DSa3VnUuRQ:Data.EnumSet\r\nFailed to install set-cover-0.0.8\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/11286ghc-pkg library2023-03-13T17:14:21ZEdward Z. Yangghc-pkg libraryOn Twitter, Anthony Cowley was wondering why there was no GHC API functions for taking Cabal InstalledPackageInfos and turning them into GHC InstalledPackageInfos. https://twitter.com/a_cowley/status/680158885953564672
No such interface...On Twitter, Anthony Cowley was wondering why there was no GHC API functions for taking Cabal InstalledPackageInfos and turning them into GHC InstalledPackageInfos. https://twitter.com/a_cowley/status/680158885953564672
No such interface exists: to keep GHC decoupled from Cabal, the GHC package representation is mediated solely by `ghc-pkg`, so the "correct" way to create a package config file, run `ghc-pkg` to load it into the GHC binary representation, and go from there.
It seems like it would be convenient if `ghc-pkg` was libified, and so people who linked against GHC and Cabal could just directly do the conversion without going through `ghc-pkg`. It's unclear what the right interface is; ghc-pkg does a number of sanity checks and it's unclear if those should be libified too. Any such library also must be uploaded to Hackage, because if you want to link against a newer version of Cabal you have to rebuild the ghc-pkg library against the newest version of Cabal.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.11 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | acowley |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc-pkg library","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["acowley"],"type":"FeatureRequest","description":"On Twitter, Anthony Cowley was wondering why there was no GHC API functions for taking Cabal InstalledPackageInfos and turning them into GHC InstalledPackageInfos. https://twitter.com/a_cowley/status/680158885953564672\r\n\r\nNo such interface exists: to keep GHC decoupled from Cabal, the GHC package representation is mediated solely by `ghc-pkg`, so the \"correct\" way to create a package config file, run `ghc-pkg` to load it into the GHC binary representation, and go from there.\r\n\r\nIt seems like it would be convenient if `ghc-pkg` was libified, and so people who linked against GHC and Cabal could just directly do the conversion without going through `ghc-pkg`. It's unclear what the right interface is; ghc-pkg does a number of sanity checks and it's unclear if those should be libified too. Any such library also must be uploaded to Hackage, because if you want to link against a newer version of Cabal you have to rebuild the ghc-pkg library against the newest version of Cabal.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/11023ghci and ghc-pkg disagree about what's exposed2019-07-07T18:32:34Zdmwitghci and ghc-pkg disagree about what's exposedI have installed vector-0.10.12.3 and vector-0.11.0.0. At some point, I had hidden both from the package database; however, I later used ghc-pkg expose to mark one as visible again. Now I seem to be in a strange state where ghci and ghc-...I have installed vector-0.10.12.3 and vector-0.11.0.0. At some point, I had hidden both from the package database; however, I later used ghc-pkg expose to mark one as visible again. Now I seem to be in a strange state where ghci and ghc-pkg disagree about what is hidden:
```
% ghci-7.10.2
GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help
Prelude> :m +Data.Vector.Unboxed
<no location info>:
Could not find module ‘Data.Vector.Unboxed’
It is a member of the hidden package ‘vector-0.11.0.0@vecto_3jMaUrldidp1bqsrn0qsS2’.
It is a member of the hidden package ‘vector-0.10.12.3@vecto_1COyUuV1LrA1IjYnWfJnbs’.
Prelude>
Leaving GHCi.
% ghc-pkg-7.10.2 list vector | cat
/usr/local/lib/ghc-7.10.2/package.conf.d:
(no packages)
/home/dmwit/.ghc/x86_64-linux-7.10.2/package.conf.d:
vector-0.10.12.3
(vector-0.11.0.0)
% ghc-pkg-7.10.2 describe vector-0.10.12.3 | grep 'key:\|exposed:'
key: vecto_1COyUuV1LrA1IjYnWfJnbs
exposed: True
```
I have tried reproducing this with other packages in a handful of ways and failed; so I can't give instructions for reproducing. But I am happy to perform any diagnostics you can think of.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.2 |
| 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":"ghci and ghc-pkg disagree about what's exposed","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I have installed vector-0.10.12.3 and vector-0.11.0.0. At some point, I had hidden both from the package database; however, I later used ghc-pkg expose to mark one as visible again. Now I seem to be in a strange state where ghci and ghc-pkg disagree about what is hidden:\r\n\r\n{{{\r\n% ghci-7.10.2 \r\nGHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help\r\nPrelude> :m +Data.Vector.Unboxed\r\n\r\n<no location info>:\r\n Could not find module ‘Data.Vector.Unboxed’\r\n It is a member of the hidden package ‘vector-0.11.0.0@vecto_3jMaUrldidp1bqsrn0qsS2’.\r\n It is a member of the hidden package ‘vector-0.10.12.3@vecto_1COyUuV1LrA1IjYnWfJnbs’.\r\nPrelude> \r\nLeaving GHCi.\r\n% ghc-pkg-7.10.2 list vector | cat\r\n/usr/local/lib/ghc-7.10.2/package.conf.d:\r\n (no packages)\r\n/home/dmwit/.ghc/x86_64-linux-7.10.2/package.conf.d:\r\n vector-0.10.12.3\r\n (vector-0.11.0.0)\r\n\r\n% ghc-pkg-7.10.2 describe vector-0.10.12.3 | grep 'key:\\|exposed:'\r\nkey: vecto_1COyUuV1LrA1IjYnWfJnbs\r\nexposed: True\r\n}}}\r\n\r\nI have tried reproducing this with other packages in a handful of ways and failed; so I can't give instructions for reproducing. But I am happy to perform any diagnostics you can think of.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/10912Support for out of the box static linking2019-07-07T18:33:05Zcrb002Support for out of the box static linkingWhen running in environments like AWS Lambda you don't have access to basic shared libraries Haskell needs like libgmp, libffi. Need good support for static linked libraries of anything included in a basic GHC distribution.
https://gith...When running in environments like AWS Lambda you don't have access to basic shared libraries Haskell needs like libgmp, libffi. Need good support for static linked libraries of anything included in a basic GHC distribution.
https://github.com/commercialhaskell/stack/issues/1032
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Support for out of the box static linking","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"When running in environments like AWS Lambda you don't have access to basic shared libraries Haskell needs like libgmp, libffi. Need good support for static linked libraries of anything included in a basic GHC distribution.\r\n\r\nhttps://github.com/commercialhaskell/stack/issues/1032","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/10798Signatures with only types should not be included in unit keys2019-07-07T18:33:50ZEdward Z. YangSignatures with only types should not be included in unit keysSuppose we want to modularize the dependence on `p` in this program:
```
unit p where
module A where
data T = T
mkT = T
unit q where
include p
module B where
import A
bar = mkT
```
The obvious signature to write f...Suppose we want to modularize the dependence on `p` in this program:
```
unit p where
module A where
data T = T
mkT = T
unit q where
include p
module B where
import A
bar = mkT
```
The obvious signature to write for `A` is:
```
signature A where
data T
mkT :: T
```
But this presupposes an implementation of `A` which exports `T`. But `B` doesn't use any export of `T`, and an equally valid implementation would be if `T` was defined in some `Types` module and then imported here.
But suppose we change our signature to be:
```
signature A.Types where
data T
signature A where
import A.Types
mkT :: T
```
This is maximally general, but requires that the module which exports `T` be named `A.Types`. If someone puts the type anywhere else, we have to rename the signature to the real place it was defined, or make a dummy implementation module which reexports the type in question.
Now there is a curious thing, which is that the choice of module we use to fill these extra signature modules currently influences the type identity of anything else in the unit. But we never rely on any code from these signatures: if I make two distinct dummy modules to set `T` to the same type, this really shouldn't have any impact (at all!) on the code generated.
So, my suggestion is that if a signature contains only types (perhaps they could be named something else, like `tysignature`), they should not count towards the calculation of a unit key. This means that a user can freely create dummy modules to fill in these types when they are instantiating; all that is being done is helping Backpack figure out what the identities of types are. (If we wanted to be fancy, Backpack could even look inside type signatures to determine some types, but let's not go there for now.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.11 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Signatures with only types should not be included in unit keys","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"⊥","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"ezyang"},"version":"7.11","keywords":["backpack"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Suppose we want to modularize the dependence on `p` in this program:\r\n\r\n{{{\r\nunit p where\r\n module A where\r\n data T = T\r\n mkT = T\r\nunit q where\r\n include p\r\n module B where\r\n import A\r\n bar = mkT\r\n}}}\r\n\r\nThe obvious signature to write for `A` is:\r\n\r\n{{{\r\nsignature A where\r\n data T\r\n mkT :: T\r\n}}}\r\n\r\nBut this presupposes an implementation of `A` which exports `T`. But `B` doesn't use any export of `T`, and an equally valid implementation would be if `T` was defined in some `Types` module and then imported here.\r\n\r\nBut suppose we change our signature to be:\r\n\r\n{{{\r\nsignature A.Types where\r\n data T\r\nsignature A where\r\n import A.Types\r\n mkT :: T\r\n}}}\r\n\r\nThis is maximally general, but requires that the module which exports `T` be named `A.Types`. If someone puts the type anywhere else, we have to rename the signature to the real place it was defined, or make a dummy implementation module which reexports the type in question.\r\n\r\nNow there is a curious thing, which is that the choice of module we use to fill these extra signature modules currently influences the type identity of anything else in the unit. But we never rely on any code from these signatures: if I make two distinct dummy modules to set `T` to the same type, this really shouldn't have any impact (at all!) on the code generated.\r\n\r\nSo, my suggestion is that if a signature contains only types (perhaps they could be named something else, like `tysignature`), they should not count towards the calculation of a unit key. This means that a user can freely create dummy modules to fill in these types when they are instantiating; all that is being done is helping Backpack figure out what the identities of types are. (If we wanted to be fancy, Backpack could even look inside type signatures to determine some types, but let's not go there for now.)","type_of_failure":"OtherFailure","blocking":[]} -->⊥Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/10680Make Backpack order-independent (again)2019-07-07T18:34:41ZEdward Z. YangMake Backpack order-independent (again)When we moved to the new `bkp` file format, we also went back to the a format which is order-dependent: that is to say, the order in which you put the declarations matters. So if you write:
```
unit p where
module A where
import B...When we moved to the new `bkp` file format, we also went back to the a format which is order-dependent: that is to say, the order in which you put the declarations matters. So if you write:
```
unit p where
module A where
import B
module B where
...
```
this fails to type-check, GHC complaining that `B` is not in scope. I did this, in part because it's what the Backpack paper described, and because it was "simpler" to implement.
I think we should move back to an order-independent scheme, for the following reasons:
1. Haskell users are used to not needing pay particularly close attention to the ordering of their modules, and forcing people to linearize their module descriptions would be spectacularly disruptive with large amounts of modules. So un-ordered modules are "more natural for a traditional Haskell user.
1. Order-independence imposes some constraints on how expressive programs are (with order-dependent Backpack, you can do some pretty tricky things by ordering things certain ways); this could simplify some aspects of compiler implementation and make Backpack easier to explain.
1. A particular case of (2): it seems a lot simpler UX-wise to let a user assume that if you import a module `M` in a unit, it doesn't matter where you import it: you always get the same set of identifiers brought into scope. Thus, the incremental results of signatures should not be visible, c.f. #10679
The main idea is that only the surface-syntax is un-ordered: the internal representation of units is a DAG which we work out in an elaboration phase, not altogether unsimilar from what `GhcMake` computes. An important auxiliary idea is that `import A` where `A` is backed by some signatures depends on EVERY signature in scope.
Here are the details:
- \*The intermediate representation.\*\* We translate into an intermediate representation which consists of a directed graph of:
• Each source-level module, signature and include, and
• Each unfilled requirement (called a “signature merge” node).
The edges of the directed graph signify a “depends on” relation, and are defined as follows:
• An include p depends on include q if, for some module name m, p requires m and q provides m.
• An include p depends on a module m if p requires a module named m.
• A module/signature m depends on include p if m imports a module provided by p.
• A module/signature m depends on a module n if m imports n.
• A module/signature m depends on a signature merge n if m imports n.
• A module/signature m depends on a signature n if m {-\# SOURCE \#-} imports n.
• A signature merge m depends on a local signature m (if it exists).
• A signature merge m depends on a include p, if the (renamed) include requires m.
- \*Elaboration.\*\* Take a Backpack file, construct this graph, and topsort it into a DAG of SCCs. SCCs with a single node are compileable as before. SCCs with multiple nodes will have to be managed with some mutual recursion mechanism; see refinements for more thoughts on this.
- \*Refinements:\*\*
1. \*\*Can a signature depend on a (home) module?\*\* Imports of this kind require a retypecheck loop. Consider this situation:
```
unit p where
signature H where
data T
module M where
import H
data S = S T
unit q where
include p
module Q where
import M
signature H where
import Q
data T = T S
```
> Here, signature H in q depends on Q. When we typecheck `Q`, we bring `M.S` into the type environment with a `TyThing` that describes the constructor as accepting an abstract type `T`. However, when we subsequently typecheck the local signature `H`, we must refine all `TyThing`s of `T` with the true description (e.g. constructor information). So you'll need to retypecheck `Q` (and `M`) in order to make sure the `TyThing` is correct.
1. \*\*Can an include depend on a (home) module?\*\* If the module has no (transitive) dependency on signatures, this is fine. However, it's easy to have a circular dependency. Consider:
```
unit p where
signature A -- imports nothing
signature B -- imports nothing
module M
unit q where
include p
module B where
import A
...
```
> `B` depends on `p` for `p/A.hsig`; however, `p` depends on `B` because this module is filling a requirement. However, if we were to include the internal graph of `p` into `q`, the resulting graph would not have an cycles; so this is one possibility of how to untangle this situation. However, if there's still a cycle (e.g. `A` imports `B`), then you will need at least a retypecheck loop, and maybe `hs-boot` style compilation. We're not going to implement this for now.
1. \*\*Can we deal with include-include dependency cycles?\*\* Yes! Just use the Backpack paper's strategy for creating a recursive unit key and compile the two packages `hs-boot` style. But I'm not planning on implementing this yet.
1. \*\*Can we deal with signature-signature dependency cycles?\*\* Ordered Backpack would have supported this:
```
unit a-sig where
signature A where
data T
unit ab-sig where
include a-sig
signature B where
import A
data S = S T
signature A where
import B
data T = T S
```
> In our model, `ab-sig` has a cycle. However, I believe any such cycle can be broken by creating sufficiently many units:
```
unit a-sig where
signature B where
data T
signature A where
data S = S T
unit b-sig where
signature A where
data S
signature B where
data T = T S
unit ab-sig where
include a-sig
include b-sig
```
> In principle, GHC could automatically break import cycles by replacing an import with an import of a reduced signature that simply has abstract type definitions. See #10681. (I'm not sure this is possible for all language features.) This technique would also work for normal modules, assuming that every function is explicitly annotated with a type.Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/10679Generalize hi-boot/hi for signatures, to manage intermediate merged interfaces2019-07-07T18:34:41ZEdward Z. YangGeneralize hi-boot/hi for signatures, to manage intermediate merged interfaces## The problem
In some situations, we need to output multiple interface
files for what is morally the same module name.
### Example 1: Merging external and home signatures
```
unit a-sig where
signature A
unit p where
include ...## The problem
In some situations, we need to output multiple interface
files for what is morally the same module name.
### Example 1: Merging external and home signatures
```
unit a-sig where
signature A
unit p where
include a-sig
signature A
```
Compiling `p/A.hsig` produces an interface file which contains just
the definitions declared in `p`. However, someone including `p`
should see the merge of the interface of `p/A.hsig` AND `a-sig/A.hsig`
(which was included.)
### Example 2: Merging two home signatures
```
unit p where
signature A
signature B where
import A
...
signature A where
import B
...
```
What should we do if a signature is specified multiple times in the same
unit? The compilation of each produces a distinct interface, and the
public interface we want to expose is the merge of the two. (And by the
way, what's the source file name of `A`, if we are not using the inline syntax?)
### Example 3: Merging a signature and a module
```
unit p where
signature A
module B where
import A
...
module A where
import B
...
```
`A` and `B` are mutually recursive, and we want to use a signature file to
break the gap. The signature produces an interface file, only to be
overwritten when we actually define the module proper.
But wait! We have a solution for this example already: the first interface
file for `A` is not saved to `A.hi`, but `A.hi-boot`...
## The proposal
I want to take the `A.hi-boot` versus `A.hi` distinction and
generalize it: we should be able to name intermediate interface
files A.1.hi, A.2.hi, ... and finally A.hi (which
is publically visible outside the unit.) This naming convention applies
to Haskell files too.
### User-visible consequences
Every signature file is numbered, and every import of a signature file
refers to a specific number. This number is unique among all other
modules in a unit which share the same name. For backwards
compatibility, some number/file name extensions are treated specially:
1. `.hs` files compile to `.hi` (implicitly numbered 0)
1. `.hs-boot` files compile to `.hi-boot` (implicitly numbered 1)
1. `.hsig` files compile to `.hi-boot` (implicitly numbered 1)
1. `.n.hsig` files compile to `.n.hi-boot` (numbered n, where n is greater than 1)
- \*Flex point:\*\* We could give `.hsig` files their own file extension
for interface files; just would require some more work to distinguish
between `hs-boot` and `hsig` as well as record the numbering.
To import, the `{-# SOURCE n #-}` pragma can be used (with `{-# SOURCE #-}`
being equivalent `{-# SOURCE 1 #-}`.)
Inline Backpack files can omit numbering, since we can figure it out
based on the ordering of declarations (numbering in REVERSE order
of occurrence). Example 2 can be numbered as follows:
```
signature {-# SOURCE 2 #-} A
signature {-# SOURCE 1 #-} B where
import {-# SOURCE 2 #-} A
...
signature {-# SOURCE 1 #-} A where
import {-# SOURCE 1 #-} B
...
```
### Internal consequences
In many places in the code today, we record a boolean indicating if
we depended on the boot interface `hi-boot` or the normal interface `hi`.
We now replace this marker with an integer which records the numbering.
The primary affected components are dependency recording in interfaces,
interface loading code in GHC, and the implementation of `--make`.
### Interaction with signature merging
Unlike `hs-boot` files, `hsig` files can be included from external
units, in which case the semantics are that all signatures in scope
are merged together. The key rule is that we \*\*generate an hi
file for each partial merge\*\*; this means that whenever we want
to typecheck a module, there is exactly one interface file per
module we import. Consider this example:
```
unit a-sig where
signature A
unit a-sig2 where
signature A
unit p where
include a-sig
module B
include a-sig2
module C
signature A
module D
```
When compiling this, we generate four interface files for `A`:
```
unit p where
include a-sig
-- Produces A.3.hi-boot (a-sig)
module B -- uses A.3.hi-boot
include a-sig2
-- Produces A.2.hi-boot (a-sig + a-sig2)
module C -- uses A.2.hi-boot
signature A
-- Produces A.hi-boot (everything)
module D -- uses A.hi-boot
-- At the end, A.hi-boot copied to A.hi to be publically visible
```
## Can we do anything simpler?
There are a few barriers to doing something simpler:
1. We can avoid generating extra interface files if we instead merge them on-the-fly when we use them. However, this forces later instances of GHC to do repeated work remerging interface files, so it seems desirable from a performance perspective to merge before writing. Another scheme is that we could merge on use for signatures in the home package, and then write out a unified file at the very end, trading off performance for less written interface files.
1. The Backpack language is defined in a way that allows modules, signatures and includes to be ordered in a semantically meaningful way. For example:
```
unit q where
signature M
signature A where
f :: Int -> Int
...
unit p where
signature A where
data T
module M where
import A -- should get T but not f
...
include q -- fill in M
module S where
import A -- should get T and f
```
> This means that even within a unit, the interface of a signature file may differ. We could rule this out, but we would have to work out how to explain this limitation to users. (For example, we could solve the example above by saying that units which define modules do not bring their signatures into scope for a package which imports them; but this is a pretty ad hoc rule! And you still have to deal with repeated signatures, or a signature importing a module importing a signature. There are a lot of cases.)
1. This problem cannot be avoided at all if you are truly doing recursive modules, since you need the intermediate interface file to do compilation at all prior to getting the real implementation.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.11 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Generalize hi-boot/hi for signatures, to manage intermediate merged interfaces","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"ezyang"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"== The problem ==\r\n\r\nIn some situations, we need to output multiple interface\r\nfiles for what is morally the same module name.\r\n\r\n=== Example 1: Merging external and home signatures ===\r\n\r\n{{{\r\nunit a-sig where\r\n signature A\r\nunit p where\r\n include a-sig\r\n signature A\r\n}}}\r\n\r\nCompiling `p/A.hsig` produces an interface file which contains just\r\nthe definitions declared in `p`. However, someone including `p`\r\nshould see the merge of the interface of `p/A.hsig` AND `a-sig/A.hsig`\r\n(which was included.)\r\n\r\n=== Example 2: Merging two home signatures ===\r\n\r\n{{{\r\nunit p where\r\n signature A\r\n signature B where\r\n import A\r\n ...\r\n signature A where\r\n import B\r\n ...\r\n}}}\r\n\r\nWhat should we do if a signature is specified multiple times in the same\r\nunit? The compilation of each produces a distinct interface, and the\r\npublic interface we want to expose is the merge of the two. (And by the\r\nway, what's the source file name of `A`, if we are not using the inline syntax?)\r\n\r\n=== Example 3: Merging a signature and a module ===\r\n\r\n{{{\r\nunit p where\r\n signature A\r\n module B where\r\n import A\r\n ...\r\n module A where\r\n import B\r\n ...\r\n}}}\r\n\r\n`A` and `B` are mutually recursive, and we want to use a signature file to\r\nbreak the gap. The signature produces an interface file, only to be\r\noverwritten when we actually define the module proper.\r\n\r\nBut wait! We have a solution for this example already: the first interface\r\nfile for `A` is not saved to `A.hi`, but `A.hi-boot`...\r\n\r\n== The proposal ==\r\n\r\nI want to take the `A.hi-boot` versus `A.hi` distinction and\r\ngeneralize it: we should be able to name intermediate interface\r\nfiles A.1.hi, A.2.hi, ... and finally A.hi (which\r\nis publically visible outside the unit.) This naming convention applies\r\nto Haskell files too.\r\n\r\n=== User-visible consequences ===\r\n\r\nEvery signature file is numbered, and every import of a signature file\r\nrefers to a specific number. This number is unique among all other\r\nmodules in a unit which share the same name. For backwards\r\ncompatibility, some number/file name extensions are treated specially:\r\n\r\n1. `.hs` files compile to `.hi` (implicitly numbered 0)\r\n\r\n2. `.hs-boot` files compile to `.hi-boot` (implicitly numbered 1)\r\n\r\n3. `.hsig` files compile to `.hi-boot` (implicitly numbered 1)\r\n\r\n4. `.n.hsig` files compile to `.n.hi-boot` (numbered n, where n is greater than 1)\r\n\r\n**Flex point:** We could give `.hsig` files their own file extension\r\nfor interface files; just would require some more work to distinguish\r\nbetween `hs-boot` and `hsig` as well as record the numbering.\r\n\r\nTo import, the `{-# SOURCE n #-}` pragma can be used (with `{-# SOURCE #-}`\r\nbeing equivalent `{-# SOURCE 1 #-}`.)\r\n\r\nInline Backpack files can omit numbering, since we can figure it out\r\nbased on the ordering of declarations (numbering in REVERSE order\r\nof occurrence). Example 2 can be numbered as follows:\r\n\r\n{{{\r\n signature {-# SOURCE 2 #-} A\r\n signature {-# SOURCE 1 #-} B where\r\n import {-# SOURCE 2 #-} A\r\n ...\r\n signature {-# SOURCE 1 #-} A where\r\n import {-# SOURCE 1 #-} B\r\n ...\r\n}}}\r\n\r\n=== Internal consequences ===\r\n\r\nIn many places in the code today, we record a boolean indicating if\r\nwe depended on the boot interface `hi-boot` or the normal interface `hi`.\r\nWe now replace this marker with an integer which records the numbering.\r\nThe primary affected components are dependency recording in interfaces,\r\ninterface loading code in GHC, and the implementation of `--make`.\r\n\r\n=== Interaction with signature merging ===\r\n\r\nUnlike `hs-boot` files, `hsig` files can be included from external\r\nunits, in which case the semantics are that all signatures in scope\r\nare merged together. The key rule is that we **generate an hi\r\nfile for each partial merge**; this means that whenever we want\r\nto typecheck a module, there is exactly one interface file per\r\nmodule we import. Consider this example:\r\n\r\n{{{\r\nunit a-sig where\r\n signature A\r\nunit a-sig2 where\r\n signature A\r\nunit p where\r\n include a-sig\r\n module B\r\n include a-sig2\r\n module C\r\n signature A\r\n module D\r\n}}}\r\n\r\nWhen compiling this, we generate four interface files for `A`:\r\n\r\n{{{\r\nunit p where\r\n include a-sig\r\n -- Produces A.3.hi-boot (a-sig)\r\n module B -- uses A.3.hi-boot\r\n include a-sig2\r\n -- Produces A.2.hi-boot (a-sig + a-sig2)\r\n module C -- uses A.2.hi-boot\r\n signature A\r\n -- Produces A.hi-boot (everything)\r\n module D -- uses A.hi-boot\r\n -- At the end, A.hi-boot copied to A.hi to be publically visible\r\n}}}\r\n\r\n== Can we do anything simpler? ==\r\n\r\nThere are a few barriers to doing something simpler:\r\n\r\n1. We can avoid generating extra interface files if we instead merge them on-the-fly when we use them. However, this forces later instances of GHC to do repeated work remerging interface files, so it seems desirable from a performance perspective to merge before writing. Another scheme is that we could merge on use for signatures in the home package, and then write out a unified file at the very end, trading off performance for less written interface files.\r\n\r\n2. The Backpack language is defined in a way that allows modules, signatures and includes to be ordered in a semantically meaningful way. For example:\r\n{{{\r\nunit q where\r\n signature M\r\n signature A where\r\n f :: Int -> Int\r\n ...\r\nunit p where\r\n signature A where\r\n data T\r\n module M where\r\n import A -- should get T but not f\r\n ...\r\n include q -- fill in M\r\n module S where\r\n import A -- should get T and f\r\n}}}\r\n This means that even within a unit, the interface of a signature file may differ. We could rule this out, but we would have to work out how to explain this limitation to users. (For example, we could solve the example above by saying that units which define modules do not bring their signatures into scope for a package which imports them; but this is a pretty ad hoc rule! And you still have to deal with repeated signatures, or a signature importing a module importing a signature. There are a lot of cases.)\r\n\r\n3. This problem cannot be avoided at all if you are truly doing recursive modules, since you need the intermediate interface file to do compilation at all prior to getting the real implementation.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Edward Z. YangEdward Z. Yang