[Lldb-commits] [PATCH] D78972: Treat hasWeakODRLinkage symbols as external in REPL computations

Thu Oct 29 14:16:22 PDT 2020

jingham added a comment.

In D78972#2353643 <https://reviews.llvm.org/D78972#2353643>, @labath wrote:

> Right -- I can understand that. I'm not sure whether this is a real issue -- I'd expect that these compiler-internal symbols would normally have private (not "internal") linkage (and hence be caught by line 330) -- but I'm not insisting on exposing all of the internal linkage symbols either.
>
> However, I think the phrase "meant to be exported" brings us back to the beginning, full circle. Objects with "weak" linkage are also "meant" to be exported (== externally visible in a normal compilation), just like their weak_odr counterparts. I think that the real bug here is that we've started special-casing individual linkage types, and that it's only a matter of time before we find ourselves needing to add another linkage type to this list. Llvm has a bunch of functions to check for the properties of linkage types, and it seems to me like we should be able to pick one of them. So, if we want to just expose the functions that would be visible during a normal compilation, the function to use is `hasLocalLinkage()` (negation of it, that is)

The REPL is weird since it formally has to compile individual expressions as "compile units" but must also pretend they aren't individual compile units, but rather a weird kind of streaming single compile unit (weird because they also allow redefinitions that wouldn't be legal if the thing were one compile unit).  So the compiler's normal notion of "localLinkage" isn't necessarily related to what the REPL needs to export.  OTOH, localLinkage also works, so I'm happy to use it for now till we come up with a reason not to.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D78972/new/

https://reviews.llvm.org/D78972