================
@@ -134,7 +134,9 @@ bool TypeQuery::ContextMatches(
if (ctx == ctx_end)
return false; // Pattern too long.
- if (ctx->kind == CompilerContextKind::Namespace && ctx->name.IsEmpty()) {
+ if ((ctx->kind & CompilerContextKind::Namespace) ==
----------------
labath wrote:
I don't know which approach is better, but I like the direction of this. I'll
just say that if you find yourself needing to parse a type name, don't
reimplement that code. I'd rather take the parsing code out of the TypeQuery
constructor, and factor it into function that can be called independently.
How expensive is this "get the parent to handle nested structs/enums/unions"
operation? I'm asking because I'm wondering if we can just do it all the time,
or if we should try to avoid it. If it's cheap, we can just construct the
precise context (one where every scope knows whether it's a type or a
namespace) every time. The advantage of that is that we can reuse the existing
infrastructure and the overall flow will be very similar to how things work in
DWARF. However, if it's expensive, then we may want to do something like you've
done here, where we first do a "fuzzy" match (just checking whether the names
match, not looking at the kinds), and then we confirm the match (if needed) by
looking at the kinds.
https://github.com/llvm/llvm-project/pull/149876
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
