<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/lldb/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp, branch users/nico/python-2</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/'/>
<entry>
<title>[lldb][TypeSystem][NFC] CreateFunctionType to take parameters by llvm::ArrayRef (#142620)</title>
<updated>2025-06-03T22:37:39+00:00</updated>
<author>
<name>Michael Buch</name>
<email>michaelbuch12@gmail.com</email>
</author>
<published>2025-06-03T22:37:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=cb56e15bb3e92c8aab2b7fd74a7683ffd83ac10b'/>
<id>cb56e15bb3e92c8aab2b7fd74a7683ffd83ac10b</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb][TypeSystemClang] Pass around enum value as uint64_t (#125244)</title>
<updated>2025-02-03T09:07:40+00:00</updated>
<author>
<name>Michael Buch</name>
<email>michaelbuch12@gmail.com</email>
</author>
<published>2025-02-03T09:07:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=f99e6df1415fa825b8329b381a23cd9c58d6edd4'/>
<id>f99e6df1415fa825b8329b381a23cd9c58d6edd4</id>
<content type='text'>
The `DWARFASTParserClang` reads enum values as `int64_t`s regardless of
the enumerators signedness. Then we pass it to
`AddEnumerationValueToEnumerationType` and only then do we create an
`APSInt` from it. However, there are other places where we read/pass
around the enum value as unsigned. This patch makes sure we consistently
use the same integer type for the enum value and let `APSInt` take care
of signedness. This shouldn't have any observable effect.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The `DWARFASTParserClang` reads enum values as `int64_t`s regardless of
the enumerators signedness. Then we pass it to
`AddEnumerationValueToEnumerationType` and only then do we create an
`APSInt` from it. However, there are other places where we read/pass
around the enum value as unsigned. This patch makes sure we consistently
use the same integer type for the enum value and let `APSInt` take care
of signedness. This shouldn't have any observable effect.</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb][TypeSystem] Ensure that ParmVarDecls have the correct DeclContext (#124279)</title>
<updated>2025-01-27T14:56:47+00:00</updated>
<author>
<name>Michael Buch</name>
<email>michaelbuch12@gmail.com</email>
</author>
<published>2025-01-27T14:56:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=081723b9db84e78d7dd240b46af2aeb3b51b00be'/>
<id>081723b9db84e78d7dd240b46af2aeb3b51b00be</id>
<content type='text'>
While sifting through this part of the code I noticed that when we parse
C++ methods, `DWARFASTParserClang` creates two sets of `ParmVarDecls`,
one in `ParseChildParameters` and once in `AddMethodToCXXRecordType`.
The former is unused when we're dealing with methods. Moreover, the
`ParmVarDecls` we created in `ParseChildParameters` were created with an
incorrect `clang::DeclContext` (namely the DeclContext of the function,
and not the function itself). In Clang, there's
`ParmVarDecl::setOwningFunction` to adjust the DeclContext of a
parameter if the parameter was created before the FunctionDecl. But we
never used it.

This patch removes the `ParmVarDecl` creation from
`ParseChildParameters` and instead creates a
`TypeSystemClang::CreateParameterDeclarations` that ensures we set the
DeclContext correctly.

Note there is one differences in how `ParmVarDecl`s would be created
now: we won't set a ClangASTMetadata entry for any of the parameters. I
don't think this was ever actually useful for parameter DIEs anyway.

This wasn't causing any concrete issues (that I know of), but was quite
surprising. And this way of setting the parameters seems easier to
reason about (in my opinion).</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
While sifting through this part of the code I noticed that when we parse
C++ methods, `DWARFASTParserClang` creates two sets of `ParmVarDecls`,
one in `ParseChildParameters` and once in `AddMethodToCXXRecordType`.
The former is unused when we're dealing with methods. Moreover, the
`ParmVarDecls` we created in `ParseChildParameters` were created with an
incorrect `clang::DeclContext` (namely the DeclContext of the function,
and not the function itself). In Clang, there's
`ParmVarDecl::setOwningFunction` to adjust the DeclContext of a
parameter if the parameter was created before the FunctionDecl. But we
never used it.

This patch removes the `ParmVarDecl` creation from
`ParseChildParameters` and instead creates a
`TypeSystemClang::CreateParameterDeclarations` that ensures we set the
DeclContext correctly.

Note there is one differences in how `ParmVarDecl`s would be created
now: we won't set a ClangASTMetadata entry for any of the parameters. I
don't think this was ever actually useful for parameter DIEs anyway.

This wasn't causing any concrete issues (that I know of), but was quite
surprising. And this way of setting the parameters seems easier to
reason about (in my opinion).</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb][TypeSystem] Pass ClangASTMetadata by-value when creating record/objc types (#102296)</title>
<updated>2024-08-07T12:05:45+00:00</updated>
<author>
<name>Michael Buch</name>
<email>michaelbuch12@gmail.com</email>
</author>
<published>2024-08-07T12:05:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=3ac5f5e1fc189d0cca169a409199fdaec13112d1'/>
<id>3ac5f5e1fc189d0cca169a409199fdaec13112d1</id>
<content type='text'>
This is a follow-up to https://github.com/llvm/llvm-project/pull/102161
where we changed the `GetMetadata`/`SetMetadata` APIs to pass
`ClangASTMetadata` by-value, instead of `ClangASTMetadata *`, which
wasn't a very friendly API.

This patch continues from there and changes
`CreateRecordType`/`CreateObjCClass` to take the metadata by-value as
well.

As a drive-by change, I also changed `DelayedAddObjCClassProperty` to
store the metadata by-value, instead of in a `std::unique_ptr`, which
AFAICT, was done solely due to the TypeSystemClang APIs taking the
metadata by pointer. This meant we could also get rid of the
user-provided copy constructors.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is a follow-up to https://github.com/llvm/llvm-project/pull/102161
where we changed the `GetMetadata`/`SetMetadata` APIs to pass
`ClangASTMetadata` by-value, instead of `ClangASTMetadata *`, which
wasn't a very friendly API.

This patch continues from there and changes
`CreateRecordType`/`CreateObjCClass` to take the metadata by-value as
well.

As a drive-by change, I also changed `DelayedAddObjCClassProperty` to
store the metadata by-value, instead of in a `std::unique_ptr`, which
AFAICT, was done solely due to the TypeSystemClang APIs taking the
metadata by pointer. This meant we could also get rid of the
user-provided copy constructors.</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Use operator==(StringRef, StringRef) instead of StringRef::equals (NFC) (#92476)</title>
<updated>2024-05-17T03:47:12+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2024-05-17T03:47:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=c33922666ce219fd6cb3341c3394f72050599552'/>
<id>c33922666ce219fd6cb3341c3394f72050599552</id>
<content type='text'>
Note that StringRef::equals has been deprecated in favor of
operator==(StringRef, StringRef).</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Note that StringRef::equals has been deprecated in favor of
operator==(StringRef, StringRef).</pre>
</div>
</content>
</entry>
<entry>
<title>[clang][NFC] Refactor `TagTypeKind` (#71160)</title>
<updated>2023-11-03T17:45:39+00:00</updated>
<author>
<name>Vlad Serebrennikov</name>
<email>serebrennikov.vladislav@gmail.com</email>
</author>
<published>2023-11-03T17:45:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=edd690b02e16e991393bf7f67631196942369aed'/>
<id>edd690b02e16e991393bf7f67631196942369aed</id>
<content type='text'>
This patch converts TagTypeKind into scoped enum. Among other benefits,
this allows us to forward-declare it where necessary.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch converts TagTypeKind into scoped enum. Among other benefits,
this allows us to forward-declare it where necessary.</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb][NFCI] TypeSystemClang::GetTypeForIdentifier should take a StringRef</title>
<updated>2023-06-16T17:44:55+00:00</updated>
<author>
<name>Alex Langford</name>
<email>alangford@apple.com</email>
</author>
<published>2023-06-15T17:31:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=4c8b6fae4437f9a5b17ddc146592aec0e4c78e02'/>
<id>4c8b6fae4437f9a5b17ddc146592aec0e4c78e02</id>
<content type='text'>
This method just takes its ConstString parameter and gets a StringRef
out of it. Let's just pass in a StringRef directly.

This also cleans up some logic in the callers to be a little easier to
read and to avoid unnecessary ConstString creation.

Differential Revision: https://reviews.llvm.org/D153054
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This method just takes its ConstString parameter and gets a StringRef
out of it. Let's just pass in a StringRef directly.

This also cleans up some logic in the callers to be a little easier to
read and to avoid unnecessary ConstString creation.

Differential Revision: https://reviews.llvm.org/D153054
</pre>
</div>
</content>
</entry>
<entry>
<title>SymbolFile: ensure that we have a value before invoking `getBitWidth`</title>
<updated>2023-03-22T18:14:13+00:00</updated>
<author>
<name>Saleem Abdulrasool</name>
<email>compnerd@compnerd.org</email>
</author>
<published>2023-03-21T16:03:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=16b7cf245ec0ff5428daee4f71af62e1938bfc73'/>
<id>16b7cf245ec0ff5428daee4f71af62e1938bfc73</id>
<content type='text'>
Ensure that the variant returned by `member-&gt;getValue()` has a value and
is not `Empty`.  Failure to do so will trigger an assertion failure in
`llvm::pdb::Variant::getBitWidth()`.  This can occur when the `static`
member is a forward declaration.

Differential Revision: https://reviews.llvm.org/D146536
Reviewed By: sgraenitz
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Ensure that the variant returned by `member-&gt;getValue()` has a value and
is not `Empty`.  Failure to do so will trigger an assertion failure in
`llvm::pdb::Variant::getBitWidth()`.  This can occur when the `static`
member is a forward declaration.

Differential Revision: https://reviews.llvm.org/D146536
Reviewed By: sgraenitz
</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb][PDB] Rename GetDeclarationForSymbol() -&gt; AddSourceInfoToDecl()</title>
<updated>2023-03-17T13:40:17+00:00</updated>
<author>
<name>Stefan Gränitz</name>
<email>stefan.graenitz@gmail.com</email>
</author>
<published>2023-03-17T13:37:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=c9987f0ac81a3d00be7627022372551bed61e6c1'/>
<id>c9987f0ac81a3d00be7627022372551bed61e6c1</id>
<content type='text'>
The old name of this function was confusing for me, when I started working on the PDB parser. The new name clearifies that the function adds file, line and column (typically referred as source info) and indicates that the information is stored in the provided decl parameter.

Reviewed By: DavidSpickett

Differential Revision: https://reviews.llvm.org/D146286
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The old name of this function was confusing for me, when I started working on the PDB parser. The new name clearifies that the function adds file, line and column (typically referred as source info) and indicates that the information is stored in the provided decl parameter.

Reviewed By: DavidSpickett

Differential Revision: https://reviews.llvm.org/D146286
</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Only allow SymbolFiles to construct Types</title>
<updated>2023-01-17T18:30:29+00:00</updated>
<author>
<name>Augusto Noronha</name>
<email>augusto2112@me.com</email>
</author>
<published>2023-01-13T21:30:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=7ef075a6d7a2bccbeedb9b5a1689e8545d5753e9'/>
<id>7ef075a6d7a2bccbeedb9b5a1689e8545d5753e9</id>
<content type='text'>
SymbolFiles should own Types by keeping them in their TypeList. This
patch privates the Type constructor to guarantee that every created Type
is kept in the SymbolFile's type list.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
SymbolFiles should own Types by keeping them in their TypeList. This
patch privates the Type constructor to guarantee that every created Type
is kept in the SymbolFile's type list.
</pre>
</div>
</content>
</entry>
</feed>
