#14808: GHC HEAD regression: GADT constructors no longer quantify tyvars in topological order -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: GADTs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14529, #14796 | Differential Rev(s): Phab:D4413 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * resolution: fixed => Comment: Richard, I'm disturbed by this. * The [http://downloads.haskell.org/~ghc/master/users- guide/glasgow_exts.html#visible-type-application spec for visible type application] says that we quantify implicit variables in left-to-right order; but that we perturb that order to respect dependency, speaking of a "table topological sort". * But I can't find a single comment or Note in the source code to point out where these things are implemented. * In the case in point for #14808, we have [https://phabricator.haskell.org/D4413 this fix] in `RnSource`. Although the comment doesn't say ''why'' the order is important, I infer (from detective work) that: * `extractHsTysRdrTyVarsDups` guarantees to return variables in left-to- right order * The `hsq_implicit` field of `LHsQTyVars` is an ''ordered'' list, specifically in left to right order. Can it contain duplicates? I think not, but again that is not duplicated. * There is a `toposortTyVars` in `TcImplicitTKBndrsX` which does the perturbing to respect dependency. But again there is zero documentation that it must be a stable topo-sort, or why. It should not take detective work to infer this info. If my suppositions are correct, could you * Document the key invariants on data types * Add a Note to explain the moving parts and * Refer to it from appropriate places. E.g. I bet the same ordering constraints apply to `hsib_ars` field of `HsImplicitBndrs`? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14808#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler