================
@@ -339,12 +405,32 @@ std::string DILParser::ParseNestedNameSpecifier() {
//
std::optional<CompilerType> DILParser::ParseTypeId() {
CompilerType type;
- // For now only allow builtin types -- will expand add to this later.
auto maybe_builtin_type = ParseBuiltinType();
if (maybe_builtin_type) {
type = *maybe_builtin_type;
- } else
- return {};
+ } else {
+ // Check to see if we have a user-defined type here.
+ // First build up the user-defined type name.
+ std::string type_name;
+ ParseTypeSpecifierSeq(type_name);
+
+ if (type_name.size() == 0)
+ return {};
+ type = ResolveTypeByName(type_name, m_ctx_scope);
+ if (!type.IsValid())
+ return {};
+
+ // Same-name identifiers should be preferred over typenames.
+ if (LookupIdentifier(type_name, m_ctx_scope, m_use_dynamic))
+ // TODO: Make type accessible with 'class', 'struct' and 'union'
keywords.
----------------
cmtice wrote:
This was copied almost directly from the implementation in lldb-eval. The
intent is, at the moment, if a user-defined type (a class or struct or union)
happens to have the same name as a user-defined variable, then when we
encounter the name we only recognize it as a variable. The TODO is to
eventually allow the user to differentiate between the two by allowing the
keywords 'class', 'struct' or 'union' to be used in front of the name when a
type is meant.
That was never actually implemented in lldb-eval, and I'm not at all sure if we
want to implement it in DIL or not. If not, I can remove the TODO's.
To answer the testing question, no I don't think the new tests add coverage for
this particular case, but I will add that in.
https://github.com/llvm/llvm-project/pull/175061
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
