Shadowing in toIface* output

[Gergő Érdi]

So does that mean Tidy produces unique `occNameFS`s, and then `Prep`
breaks them?

On Fri, Apr 1, 2022 at 10:35 PM Josh Meredith
<joshmeredith2008 at gmail.com> wrote:
>
> Hi,
>
> I encountered this when we used that for Plutus. I'll have to dig up the details, but IIRC `toIfaceExpr` expects GHC to have already tidied the output, which deals with this issue of overlapping variable names.
>
> Cheers,
> Josh
>
> On Sat, 2 Apr 2022 at 01:26, ÉRDI Gergő <gergo at erdi.hu> 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
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs