felipepiovezan wrote: >Since clang no longer emits entry for:
But what does the `debug_info` section look like? In particular, what is the _parent_ of the class DIE? If the parent of `InnerState` is not some kind of entry for `State` (either a declaration or a definition), IMO Clang is generating incorrect information for the type. What caused Clang to stop emitting these entries? > This gets a bit fuzzy, I think. The spec appears to allow this behavior (_In > such a case, a parent attribute may point to a nameless index entry (...), or > it may point to the **nearest ancestor that does have an index entry**._), > but I don't think this is particularly useful. I think it would be better to > have the parent point to the definition in the type unit (streching the > meaning of "parent" in the spec), or use one of those nameless entries to > point to the physical (declaration) parent) > > (IANAL YMMV) We can discuss this, but I think the point is going to be moot given what I mentioned about. The debug_names section is reflecting the state of `debug_info`. If the `debug_info` is saying that `State` is not a parent of `InnerState`, the `debug_names` section is correct in the literal sense, but will produce incorrect results for the query: "find A::B::State::InnerState". In the case where the declaration is there, debug_names will have correct info for `InnerState`: it will just say the parent is not indexed and things work out just fine. > have the parent point to the definition in the type unit (streching the > meaning of "parent" in the spec), Why do you say this is stretching the meaning of parent? This looks fine to me, but it seems impossible to emit such debug_names section if the compiler is no longer emitting the declaration with the type signature. (we'd need to check if the emitter code has some way of finding the definition, but also how could it possibly know there is a type between any two Parent-Child nodes? It really feels like we can't just elide the definition). https://github.com/llvm/llvm-project/pull/91808 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
