#12415: Fancy BinIface encoding for tuples is broken for constraint tuples -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12357 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Earlier today it occurred to me that `putName` already does a finite map lookup which made me think twice about the approach I took in #12357, {{{#!hs knownKeyNamesMap :: UniqFM Name knownKeyNamesMap = listToUFM_Directly [(nameUnique n, n) | n <- knownKeyNames] putName :: BinDictionary -> BinSymbolTable -> BinHandle -> Name -> IO () putName _dict BinSymbolTable{...} bh name | name `elemUFM` knownKeyNamesMap , let (c, u) = unpkUnique (nameUnique name) -- INVARIANT: (ord c) fits in 8 bits = ... }}} `knownKeyNamesMap` is currently used for two things, * A membership check is made when encoding a name in `putName` so we know that the `Name` can be encoded as just its unique. * A lookup is done in `getSymtabName` to recover the `Name` from the unique during deserialization The fact that we already do a lookup here puts an option for resolving this issue (as well as the tuple type representation issue of #12357) back on the table which I had previously ruled out in ticket:12357#comment:29. The idea is that we simply keep a lookup data structure containing `Name`s of things that need special treatment during interface file serialization. Indeed this is precisely what `knownKeyNamesMap` is. One option here would be to add the `Name`s of constraint tuples to this map and change it's type a bit, {{{#!hs data KnownKeyThing = -- | Tuple things get a fancy encoding of their own. -- While tuple type and data constructors are wired-in and therefore -- easy to spot, type reps are merely known key so we need to identify -- them by a look-up in 'knownKeyThingsMap'. TupleTypeRep !TupleSort !Arity -- | Constraint tuples. Only the 'TyCon's of these are known key. | CTupleTyCon !Arity -- | Boxed and unboxed sums (these have a similar encoding to tuples) | SumTyCon !Boxity !Arity | SumDataCon !Boxity !Arity !ConTagZ -- | Something which we know the key of; these things -- we encode in the interface file as just their 'Unique' | KnownKeyName Name knownKeyThingsMap :: NameEnv KnownKeyThing knownKeyThingsMap = mkNameEnv $ known_key_things ++ tuple_typerep_things ++ ctuple_things where known_key_things = [ (name, KnownKeyName name) | names <- knownKeyNames ] ctuple_things = [ (cTupleTyConName arity, CTupleTyCon arity) | arity <- [2..mAX_TUPLE_SIZE] ] tuple_typerep_things = [ (rep_name, TupleTypeRep tup_sort arity) | tup_sort <- [BoxedTuple, UnboxedTuple] , arity <- [2..mAX_TUPLE_SIZE] , let Just rep_name = tyConRepName_maybe $ tupleTyCon boxity arity ] }}} We'd then just modify the logic in `putName` to do the appropriate thing with the result of the lookup from this map. The deserialization side of things should be similarly straightforward (decoding the encoded `KnownKeyThing` and then doing what is necessary to turn it into a `Name`). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12415#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12415: Fancy BinIface encoding for tuples is broken for constraint tuples -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12357 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"34d933d6a821edf5abfcbee76d9325362fc28a13/ghc" 34d933d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="34d933d6a821edf5abfcbee76d9325362fc28a13" Clean up handling of known-key Names in interface files Previously BinIface had some dedicated logic for handling tuple names in the symbol table. As it turns out, this logic was essentially dead code as it was superceded by the special handling of known-key things. Here we cull the tuple code-path and use the known-key codepath for all tuple-ish things. This had a surprising number of knock-on effects, * constraint tuple datacons had to be made known-key (previously they were not) * IfaceTopBndr was changed from being a synonym of OccName to a synonym of Name (since we now need to be able to deserialize Names directly from interface files) * the change to IfaceTopBndr complicated fingerprinting, since we need to ensure that we don't go looking for the fingerprint of the thing we are currently fingerprinting in the fingerprint environment (see notes in MkIface). Handling this required distinguishing between binding and non-binding Name occurrences in the Binary serializers. * the original name cache logic which previously lived in IfaceEnv has been moved to a new NameCache module * I ripped tuples and sums out of knownKeyNames since they introduce a very large number of entries. During interface file deserialization we use static functions (defined in the new KnownUniques module) to map from a Unique to a known-key Name (the Unique better correspond to a known-key name!) When we need to do an original name cache lookup we rely on the parser implemented in isBuiltInOcc_maybe. * HscMain.allKnownKeyNames was folded into PrelInfo.knownKeyNames. * Lots of comments were sprinkled about describing the new scheme. Updates haddock submodule. Test Plan: Validate Reviewers: niteria, simonpj, austin, hvr Reviewed By: simonpj Subscribers: simonmar, niteria, thomie Differential Revision: https://phabricator.haskell.org/D2467 GHC Trac Issues: #12532, #12415 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12415#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12415: Fancy BinIface encoding for tuples is broken for constraint tuples -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12357 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Hooray! Well done Ben. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12415#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler