I have opened #21333 to track this poor documentation of tidyProgram. Zubin may be right about implicit bindings (as I remark in the ticket) but if so we should fix that so that the no-shadowing invariant does hold. I don't want clients to have to work around this, as Zubin implies HLS is doing.
If it doesn't, can someone add a repo case? Would someone like to put up an MR for #21333? -- I have made a stab in the ticket itself. Simon On Fri, 1 Apr 2022 at 15:40, Zubin Duggal <zu...@well-typed.com> wrote: > 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@haskell.org > >http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
