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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
