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

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In D78972#2035420 <https://reviews.llvm.org/D78972#2035420>, @compnerd wrote:

> WeakODR requires that the symbol actually be discarded if not referenced.  This will preserve the symbol even if unreferenced will it not?  One approach might be to just create a `DenseMap` and check for any references and mark is as preserved otherwise just drop it.  However, it _is_ ODR, which means that if it ever gets instantiated, we are well within our rights to give you the second definition rather than the first.


The question I am stuck at here is "referenced by who". E.g. does a subsequent top-level expression count? If so, then we can't drop it ever, because we don't know if they use will try to reference it in the future?

The reason I am stuck is because it's not clear to me which "model" is our expression evaluation try to emulate. The model closest to the current implementation (and also most reasonable sounding model, for me) seems to be to treat each expression as if it was defined in a separate translation unit, and then "linked" together. In that world, I think we should basically treat all non-private (static) linkage types as "external", as all of these are visible in other TUs (with slightly differing semantics, which are also hard to nail down because of the strangeness of the debugger expression evaluation model).

OTOH, in this model, it should be possible to declare the same "static" variable/function twice, but this currently fails with:

  (lldb) expr --top-level -- static void myfunc() {}
  (lldb) expr --top-level -- static void myfunc() {}
  error: <user expression 4>:1:13: redefinition of 'myfunc'
  static void myfunc() {}
              ^
  <user expression 3>:1:13: previous definition is here
  static void myfunc() {}
              ^

If that is intentional (i.e., not a bug) then a closer model would be to treat all expressions as belonging to a single translation unit, and the notion of externality does not make much sense (we could treat pretty much all linkage types the same way).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78972