@@ -897,32 +895,39 @@ TypeSP DWARFASTParserClang::ParseEnum(const SymbolContext
&sc,
}
CompilerType clang_type = m_ast.CreateEnumerationType(
- attrs.name.GetStringRef(), GetClangDeclContextContainingDIE(die,
nullptr),
- GetOwningClangModule(die), attrs.decl, e
@@ -897,32 +895,39 @@ TypeSP DWARFASTParserClang::ParseEnum(const SymbolContext
&sc,
}
CompilerType clang_type = m_ast.CreateEnumerationType(
- attrs.name.GetStringRef(), GetClangDeclContextContainingDIE(die,
nullptr),
- GetOwningClangModule(die), attrs.decl, e
@@ -897,32 +895,39 @@ TypeSP DWARFASTParserClang::ParseEnum(const SymbolContext
&sc,
}
CompilerType clang_type = m_ast.CreateEnumerationType(
- attrs.name.GetStringRef(), GetClangDeclContextContainingDIE(die,
nullptr),
- GetOwningClangModule(die), attrs.decl, e
https://github.com/labath closed https://github.com/llvm/llvm-project/pull/96484
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath wrote:
> > > This patch as-is is NFC?
> >
> >
> > NFC_**I**_, I would say :) I don't think this should change the behavior in
> > any way, but it's pretty hard to guarantee that.
>
> Sure enough - I take any claim as a statement of intent/belief, not of
> something mathematically prov
dwblaikie wrote:
> > This patch as-is is NFC?
>
> NFC_**I**_, I would say :) I don't think this should change the behavior in
> any way, but it's pretty hard to guarantee that.
Sure enough - I take any claim as a statement of intent/belief, not of
something mathematically proved, etc.
> > (n
labath wrote:
> This patch as-is is NFC?
NFC**I**, I would say :) I don't think this should change the behavior in any
way, but it's pretty hard to guarantee that.
> (no tests) but without this patch, the other delay-definition-die patch would
> have had a problem?
>
> Is it possible to add a
dwblaikie wrote:
This patch as-is is NFC? (no tests) but without this patch, the other
delay-definition-die patch would have had a problem?
Is it possible to add a test in this patch that would exercise the thing that
would become buggy if the delay-definition-die patch were to be recommitted?
Michael137 wrote:
Latest update LGTM
https://github.com/llvm/llvm-project/pull/96484
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath wrote:
> Makes sense to me Do we make sure that the type lookup map is updated so we
> don't re-parse when calling `ParseTypeFromDWARF` with either the declaration
> or the definition DIE?
Good catch. I've been meaning to add that, but I forgot. Things should still
work even without th
https://github.com/labath updated
https://github.com/llvm/llvm-project/pull/96484
>From 52db8db036c24264647340c15ec4ee6d3553cf60 Mon Sep 17 00:00:00 2001
From: Pavel Labath
Date: Mon, 24 Jun 2024 11:17:47 +0200
Subject: [PATCH 1/2] [lldb/DWARF] Remove parsing recursion when searching for
defin
https://github.com/Michael137 approved this pull request.
Makes sense to me
Do we make sure that the type lookup map is updated so we don't re-parse when
calling `ParseTypeFromDWARF` with either the declaration or the definition DIE?
https://github.com/llvm/llvm-project/pull/96484
_
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Pavel Labath (labath)
Changes
If ParseStructureLikeDIE (or ParseEnum) encountered a declaration DIE, it would
call FindDefinitionTypeForDIE. This returned a fully formed type, which it
achieved by recursing back into ParseStructureLikeDIE
https://github.com/labath created
https://github.com/llvm/llvm-project/pull/96484
If ParseStructureLikeDIE (or ParseEnum) encountered a declaration DIE, it would
call FindDefinitionTypeForDIE. This returned a fully formed type, which it
achieved by recursing back into ParseStructureLikeDIE wit
14 matches
Mail list logo
