Shadowing in toIface* output

[Zubin Duggal]

I suspect these are implicit bindings that you will need to filter out
and regenerate from the tycons.

You might find this HLS PR instructive as it implements something quite similar
to what you seem to want: https://github.com/haskell/haskell-language-server/pull/2813

It is also relevant to question about OtherCon and unfoldings you asked
earlier, as it implements a workaround for ignoring this information
during testing of the generated core. Fortunately we don't need to care
about this as we only use the serialized core to generate bytecode,
where this information is not relevant.

I believe the only reason OtherCon isn't zapped by corePrep in GHC is
because core lint tends to complain if it is.

Cheers,
Zubin.

On 22/04/01 22:25, ÉRDI Gergő wrote:
>Hi,
>
>I'm trying to save (Prep'd) Core bindings right next to the serialized 
>`ModIface` (so basically `put_`ing them into the same bytestream, 
>after the `ModIface`), and that's exactly what the functions in 
>`GHC.CoreToIface` seem to be for, so I expected it to Just Work. 
>However, I noticed that I very frequently get problems with shadowing. 
>For example, Core that looks like `\v{u1} v{u2} -> v{u1}` would get 
>translated to `\v v -> v`, which is disastrous since these locally 
>bound `Var`s are represented as just their `getOccFS` (i.e. the 
>`FastString` `"v"`).
>
>But this can't be right: if `toIfaceExpr` &c. would fail this 
>blatently, then the unfoldings couldn't be saved & restored, which is 
>something GHC itself does as part of normal `.hi` file handling. So 
>clearly I must be doing something wrong.
>
>So I guess my question could be, what could be causing `toIfaceExpr` 
>(a pure function!) to behave this way for my Cores? But then, if I 
>look at the implementation of `toIface*`, I can see that it really 
>doesn't do anything smarter than just storing `getOccFS` in the 
>interface (no uniques in sight)-- so maybe my *real* question is, what 
>is GHC itself doing so that it doesn't have this same problem?
>
>Thanks,
>	Gergo
>_______________________________________________
>ghc-devs mailing list
>ghc-devs at haskell.org
>http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs