#8407: Module re-exports at the package level -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): This is primarily a Cabal question, isn't it? If Cabal wants to move this way, I'd be happy for GHC to move to accommodate. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8407#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8407: Module re-exports at the package level -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ezyang): Hello nomeata, are you still working on this? This is on the hotpath for Backpack implementation work so I will probably go ahead and implement this if you are not working on it. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8407#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8407: Module re-exports at the package level -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.6.3 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): Not working on it here, so please do go ahead. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8407#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8407: Module re-exports at the package level -------------------------------------+------------------------------------ Reporter: nomeata | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.6.3 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ezyang): Here is an annoying problem for implementing this functionality. Module reexports should roughly be analogous to how we deal with type/declaration reexports at the Haskell source level. To briefly overview how that mechanism works, we have a phase of compilation called "renaming", which takes all identifiers and figures out what true names they refer to. This is done by consulting the hi files associated with imported modules, which record the original name of any identifiers they export. By analogy, the installed package information file is like an "hi" file, and we would like it to store a pointer to the original name of the module (in this case, the InstalledPackageId and original module name, if renaming is allowed.) However, there is trouble in paradise. Entries in the InstalledPackageDb are created by the Cabal library; however, the Cabal library has no knowledge about module resolution (it only looks at the dependencies to do dependency resolution): all of this logic is in GHC proper (Packages and Finder). So at the time Cabal is writing the installed package info, it would need to consult GHC in order to figure out where modules actually came from! This seems like a design smell. The alternative is to do module resolution in GHC. Here, we augment the creation of our module map (when processing `-package` flags) so that when we see a reexport, we consult the existing map and insert a pointer to precisely the original import. If the packages are passed to us in topologically sorted order (which Cabal seems to do today), then we only pay the cost of a single map lookup for every reexported module we encounter. The downside is that this mechanism is now no longer symmetric with original names. It's not really clear which one is better. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8407#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8407: Module re-exports at the package level -------------------------------------+------------------------------------ Reporter: nomeata | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.6.3 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ezyang): SPJ thought of a good way around the implementation problem: we should implement a "mini" module finder in ghc-pkg, which simply takes all of the dependencies listed in the package, and reads their entries in order to resolve a module reexport. We hold the invariant that reexports in the installed package database point to the original name, so once we find the relevant entry, we know the original name. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8407#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8407: Module re-exports at the package level -------------------------------------+------------------------------------ Reporter: nomeata | Owner: ezyang Type: feature request | Status: new Priority: high | Milestone: Component: Package system | Version: 7.6.3 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by ezyang): * priority: normal => high -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8407#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8407: Module re-exports at the package level -------------------------------------+------------------------------------ Reporter: nomeata | Owner: ezyang Type: feature request | Status: new Priority: high | Milestone: 7.10.1 Component: Package system | Version: 7.6.3 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Edward Z. Yang ): In [changeset:"7f5c10864e7c26b90c7ff4ed09d00c8a09aa4349/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7f5c10864e7c26b90c7ff4ed09d00c8a09aa4349" Module reexports, fixing #8407. The general approach is to add a new field to the package database, reexported-modules, which considered by the module finder as possible module declarations. Unlike declaring stub module files, multiple reexports of the same physical package at the same name do not result in an ambiguous import. Has submodule updates for Cabal and haddock. NB: When a reexport renames a module, that renaming is *not* accessible from inside the package. This is not so much a deliberate design choice as for implementation expediency (reexport resolution happens only when a package is in the package database.) TODO: Error handling when there are duplicate reexports/etc is not very well tested. Signed-off-by: Edward Z. Yang Conflicts: compiler/main/HscTypes.lhs testsuite/.gitignore utils/haddock }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8407#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8407: Module re-exports at the package level -------------------------------------+------------------------------------- Reporter: nomeata | Owner: ezyang Type: feature | Status: closed request | Milestone: 7.10.1 Priority: high | Version: 7.6.3 Component: Package | Keywords: backpack system | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jrp): This fix seems to break the current master build on OS X: {{{ compiler/main/Packages.lhs:867:16: error: unterminated function-like macro invocation where -- ASSERT(m == m' && pkg == pkg' && e == e' ^ compiler/HsVersions.h:39:9: note: macro 'ASSERT' defined here #define ASSERT(e) if debugIsOn && not (e) then (assertPanic __FILE__ __LINE__) else ^ 1 error generated. <> make[1]: *** [compiler/stage1/build/.depend-v.haskell] Error 1 make: *** [all] Error 2 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8407#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8407: Module re-exports at the package level -------------------------------------+------------------------------------- Reporter: nomeata | Owner: ezyang Type: feature | Status: closed request | Milestone: 7.10.1 Priority: high | Version: 7.6.3 Component: Package | Keywords: backpack system | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ezyang): I pushed a bandaid fix {{{ commit 9487305393307d5eb34069c5821c11bb98b5ec90 Author: Edward Z. Yang Date: Sat Jul 26 10:41:28 2014 +0100 Fix build on OS X due to macro-like string in comment Signed-off-by: Edward Z. Yang }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8407#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler