I took a look at this today. I found > Note [GlobalId/LocalId] > ~~~~~~~~~~~~~~~~~~~~~~~ > A GlobalId is > * always a constant (top-level) > * imported, or data constructor, or primop, or record selector > * has a Unique that is globally unique across the whole > GHC invocation (a single invocation may compile multiple modules) > * never treated as a candidate by the free-variable finder; > it's a constant! > > A LocalId is > * bound within an expression (lambda, case, local let(rec)) > * or defined at top level in the module being compiled > * always treated as a candidate by the free-variable finder > > After CoreTidy, top-level LocalIds are turned into GlobalIds
This suggests that the output you're seeing -- with "lid" in QQQ and "gid" in PPP -- is correct. What has drawn your attention to this problem? Is there something else that's misbehaving? Thanks, Richard > On Aug 25, 2021, at 4:16 PM, Yiyun Liu <liuyi...@terpmail.umd.edu> wrote: > > Hi all, > > We have a function in Liquidhaskell's code base for converting > refinement expressions into GHC's core expressions using the GHC API. > Its implementation is based on tcRnExpr > <https://gitlab.haskell.org/ghc/ghc/-/blob/ghc-8.10.6-release/compiler/typecheck/TcRnDriver.hs#L2358>except > we keep the typechecked expression and desugar it before returning. > > However, our function fails to set the idScope information properly when > LiquidHaskell is invoked as a plugin (installed as a > typeCheckResultAction). This repo > <https://github.com/yiyunliu/ghc-elaboration-test>contains a minimal > example that demonstrates the issue. In the CoreExpr returned by > elabRnExpr > <https://github.com/yiyunliu/ghc-elaboration-test/blob/cb7397884b7949e6b7fb6617ded10e86ee5dcad2/src/Test/Plugin.hs#L71>, > every symbol from the current module that's being compiled is labeled as > local. The README.md file shows how the exported symbol testPlus is > marked as local in QQQ.hs, the module where it's defined. > > Is there a function we should call to set the idScope information properly? > > Thanks, > > -Yiyun > > _______________________________________________ > 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