[clang][utils] Remove ClangDataFormat.py for now #96385
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This formatter doesn't currently provide much value. It only formats `SourceLocation` and `QualType`. The only formatting it does for `QualType` is call `getAsString()` on it. The main motivator for the removal however is that the formatter implementation can be very slow (since it uses the expression evaluator in non-trivial ways). Not infrequently do we get reports about LLDB being slow when debugging Clang, and it turns out the user was loading `ClangDataFormat.py` in their `.lldbinit` by default. We should eventually develop proper formatters for Clang data-types, but these are currently not ready. So this patch removes them in the meantime to avoid users shooting themselves in the foot, and giving the wrong impression of these being reference implementations.
Michael137
requested review from
kastiglione,
JDevlieghere,
adrian-prantl and
Endilll
|
@llvm/pr-subscribers-clang Author: Michael Buch (Michael137) ChangesThis formatter doesn't currently provide much value. It only formats The main motivator for the removal however is that the formatter implementation can be very slow (since it uses the expression evaluator in non-trivial ways). Not infrequently do we get reports about LLDB being slow when debugging Clang, and it turns out the user was loading We should eventually develop proper formatters for Clang data-types, but these are currently not ready. So this patch removes them in the meantime to avoid users shooting themselves in the foot, and giving the wrong impression of these being reference implementations. Full diff: https://github.com/llvm/llvm-project/pull/96385.diff 1 Files Affected:
diff --git a/clang/utils/ClangDataFormat.py b/clang/utils/ClangDataFormat.py
deleted file mode 100644
index 28c32a123bdf9..0000000000000
--- a/clang/utils/ClangDataFormat.py
+++ /dev/null
@@ -1,170 +0,0 @@
-"""lldb data formatters for clang classes.
-
-Usage
---
-import this file in your ~/.lldbinit by adding this line:
-
-command script import /path/to/ClangDataFormat.py
-
-After that, instead of getting this:
-
-(lldb) p Tok.Loc
-(clang::SourceLocation) $0 = {
- (unsigned int) ID = 123582
-}
-
-you'll get:
-
-(lldb) p Tok.Loc
-(clang::SourceLocation) $4 = "/usr/include/i386/_types.h:37:1" (offset: 123582, file, local)
-"""
-
-import lldb
-
-
-def __lldb_init_module(debugger, internal_dict):
- debugger.HandleCommand(
- "type summary add -F ClangDataFormat.SourceLocation_summary clang::SourceLocation"
- )
- debugger.HandleCommand(
- "type summary add -F ClangDataFormat.QualType_summary clang::QualType"
- )
-
-
-def SourceLocation_summary(srcloc, internal_dict):
- return SourceLocation(srcloc).summary()
-
-
-def QualType_summary(qualty, internal_dict):
- return QualType(qualty).summary()
-
-
-class SourceLocation(object):
- def __init__(self, srcloc):
- self.srcloc = srcloc
- self.ID = srcloc.GetChildAtIndex(0).GetValueAsUnsigned()
- self.frame = srcloc.GetFrame()
-
- def offset(self):
- return getValueFromExpression(self.srcloc, ".getOffset()").GetValueAsUnsigned()
-
- def isInvalid(self):
- return self.ID == 0
-
- def isMacro(self):
- return getValueFromExpression(self.srcloc, ".isMacroID()").GetValueAsUnsigned()
-
- def isLocal(self, srcmgr_path):
- return self.frame.EvaluateExpression(
- "(%s).isLocalSourceLocation(%s)"
- % (srcmgr_path, getExpressionPath(self.srcloc))
- ).GetValueAsUnsigned()
-
- def getPrint(self, srcmgr_path):
- print_str = getValueFromExpression(
- self.srcloc, ".printToString(%s)" % srcmgr_path
- )
- return print_str.GetSummary()
-
- def summary(self):
- if self.isInvalid():
- return "<invalid loc>"
- srcmgr_path = findObjectExpressionPath("clang::SourceManager", self.frame)
- if srcmgr_path:
- return "%s (offset: %d, %s, %s)" % (
- self.getPrint(srcmgr_path),
- self.offset(),
- "macro" if self.isMacro() else "file",
- "local" if self.isLocal(srcmgr_path) else "loaded",
- )
- return "(offset: %d, %s)" % (
- self.offset(),
- "macro" if self.isMacro() else "file",
- )
-
-
-class QualType(object):
- def __init__(self, qualty):
- self.qualty = qualty
-
- def getAsString(self):
- std_str = getValueFromExpression(self.qualty, ".getAsString()")
- return std_str.GetSummary()
-
- def summary(self):
- desc = self.getAsString()
- if desc == '"NULL TYPE"':
- return "<NULL TYPE>"
- return desc
-
-
-# Key is a (function address, type name) tuple, value is the expression path for
-# an object with such a type name from inside that function.
-FramePathMapCache = {}
-
-
-def findObjectExpressionPath(typename, frame):
- func_addr = frame.GetFunction().GetStartAddress().GetFileAddress()
- key = (func_addr, typename)
- try:
- return FramePathMapCache[key]
- except KeyError:
- # print "CACHE MISS"
- path = None
- obj = findObject(typename, frame)
- if obj:
- path = getExpressionPath(obj)
- FramePathMapCache[key] = path
- return path
-
-
-def findObject(typename, frame):
- def getTypename(value):
- # FIXME: lldb should provide something like getBaseType
- ty = value.GetType()
- if ty.IsPointerType() or ty.IsReferenceType():
- return ty.GetPointeeType().GetName()
- return ty.GetName()
-
- def searchForType(value, searched):
- tyname = getTypename(value)
- # print "SEARCH:", getExpressionPath(value), value.GetType().GetName()
- if tyname == typename:
- return value
- ty = value.GetType()
- if not (
- ty.IsPointerType()
- or ty.IsReferenceType()
- or
- # FIXME: lldb should provide something like getCanonicalType
- tyname.startswith("llvm::IntrusiveRefCntPtr<")
- or tyname.startswith("llvm::OwningPtr<")
- ):
- return None
- # FIXME: Hashing for SBTypes does not seem to work correctly, uses the typename instead,
- # and not the canonical one unfortunately.
- if tyname in searched:
- return None
- searched.add(tyname)
- for i in range(value.GetNumChildren()):
- child = value.GetChildAtIndex(i, 0, False)
- found = searchForType(child, searched)
- if found:
- return found
-
- searched = set()
- value_list = frame.GetVariables(True, True, True, True)
- for val in value_list:
- found = searchForType(val, searched)
- if found:
- return found if not found.TypeIsPointerType() else found.Dereference()
-
-
-def getValueFromExpression(val, expr):
- return val.GetFrame().EvaluateExpression(getExpressionPath(val) + expr)
-
-
-def getExpressionPath(val):
- stream = lldb.SBStream()
- val.GetExpressionPath(stream)
- return stream.GetData()
|
JDevlieghere
approved these changes
Jun 22, 2024
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/18/builds/384 Here is the relevant piece of the build log for the reference: |
Seems unrelated |
|
LGTM
Yes, I'm still working on that in background. LLDB has to have a way to understand custom RTTI we use in AST nodes for statements and types, because adding a vtable pointer will increase memory pressure. I'm working on such mechanism, and that's why it's taking so long. |
Thanks, greatly appreciated! |
AlexisPerry
pushed a commit
to llvm-project-tlp/llvm-project
that referenced
this pull request
Jul 9, 2024
This formatter doesn't currently provide much value. It only formats `SourceLocation` and `QualType`. The only formatting it does for `QualType` is call `getAsString()` on it. The main motivator for the removal however is that the formatter implementation can be very slow (since it uses the expression evaluator in non-trivial ways). Not infrequently do we get reports about LLDB being slow when debugging Clang, and it turns out the user was loading `ClangDataFormat.py` in their `.lldbinit` by default. We should eventually develop proper formatters for Clang data-types, but these are currently not ready. So this patch removes them in the meantime to avoid users shooting themselves in the foot, and giving the wrong impression of these being reference implementations.
emaxx-google
added a commit
to emaxx-google/llvm-project
that referenced
this pull request
Nov 27, 2024
The script was removed in llvm#96385. Instead, mention the LLVM formatter as it's still very useful for Clang's code.
emaxx-google
added a commit
to emaxx-google/llvm-project
that referenced
this pull request
Nov 27, 2024
The script was removed in llvm#96385. Instead, mention the LLVM formatter as it's still very useful for Clang's code.
Michael137
pushed a commit
that referenced
this pull request
Dec 4, 2024
The script was removed in #96385. Instead, mention the LLVM formatter as it's still very useful for Clang's code.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This formatter doesn't currently provide much value. It only formats
SourceLocationandQualType. The only formatting it does forQualTypeis callgetAsString()on it.The main motivator for the removal however is that the formatter implementation can be very slow (since it uses the expression evaluator in non-trivial ways).
Not infrequently do we get reports about LLDB being slow when debugging Clang, and it turns out the user was loading
ClangDataFormat.pyin their.lldbinitby default.We should eventually develop proper formatters for Clang data-types, but these are currently not ready. So this patch removes them in the meantime to avoid users shooting themselves in the foot, and giving the wrong impression of these being reference implementations.