<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/lldb/source/Plugins/SymbolFile/NativePDB/PdbAstBuilder.cpp, branch main</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>Reland "[LLDB][NativePDB] Create functions with mangled name" (#161678)</title>
<updated>2025-10-07T17:27:16+00:00</updated>
<author>
<name>nerix</name>
<email>nerixdev@outlook.de</email>
</author>
<published>2025-10-07T17:27:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=3b14414cbdb8bd37ff861862a99a47104b87765b'/>
<id>3b14414cbdb8bd37ff861862a99a47104b87765b</id>
<content type='text'>
Relands #149701 which was reverted in
https://github.com/llvm/llvm-project/commit/185ae5cdc695248b58ae017508cc764c19bee5b7
because it broke demangling of Itanium symbols on i386.

The last commit in this PR adds the fix for this (discussed in #160930).
On x86 environments, the prefix of `__cdecl` functions will now be
removed to match DWARF. I opened #161676 to discuss this for the other
calling conventions.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Relands #149701 which was reverted in
https://github.com/llvm/llvm-project/commit/185ae5cdc695248b58ae017508cc764c19bee5b7
because it broke demangling of Itanium symbols on i386.

The last commit in this PR adds the fix for this (discussed in #160930).
On x86 environments, the prefix of `__cdecl` functions will now be
removed to match DWARF. I opened #161676 to discuss this for the other
calling conventions.</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "[LLDB][NativePDB] Create functions with mangled name (#149701)"</title>
<updated>2025-09-25T20:15:04+00:00</updated>
<author>
<name>Martin Storsjö</name>
<email>martin@martin.st</email>
</author>
<published>2025-09-25T20:13:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=185ae5cdc695248b58ae017508cc764c19bee5b7'/>
<id>185ae5cdc695248b58ae017508cc764c19bee5b7</id>
<content type='text'>
This reverts commit e98f34eb08b2bf7aed787e7f8a7cea9111f044c8.

This broke demangling of Itanium symbols on i386.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit e98f34eb08b2bf7aed787e7f8a7cea9111f044c8.

This broke demangling of Itanium symbols on i386.
</pre>
</div>
</content>
</entry>
<entry>
<title>[LLDB][NativePDB] Create functions with mangled name (#149701)</title>
<updated>2025-09-24T14:12:54+00:00</updated>
<author>
<name>nerix</name>
<email>nerixdev@outlook.de</email>
</author>
<published>2025-09-24T14:12:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=e98f34eb08b2bf7aed787e7f8a7cea9111f044c8'/>
<id>e98f34eb08b2bf7aed787e7f8a7cea9111f044c8</id>
<content type='text'>
Before, functions created using the NativePDB plugin would not know
about their mangled name. This showed when printing a stacktrace. There,
only the function name was shown. For
https://github.com/llvm/llvm-project/issues/143149, the mangled function
name is required to separate different parts.

This PR adds that name if available.

The Clang AST nodes also take in a mangled name, which was previously
unset. I don't think this unblocks anything further, because Clang can
mangle the function anyway.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Before, functions created using the NativePDB plugin would not know
about their mangled name. This showed when printing a stacktrace. There,
only the function name was shown. For
https://github.com/llvm/llvm-project/issues/143149, the mangled function
name is required to separate different parts.

This PR adds that name if available.

The Clang AST nodes also take in a mangled name, which was previously
unset. I don't think this unblocks anything further, because Clang can
mangle the function anyway.</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb][TypeSystem] Enable colored AST dump (#86159)</title>
<updated>2025-09-15T17:03:55+00:00</updated>
<author>
<name>Michael Buch</name>
<email>michaelbuch12@gmail.com</email>
</author>
<published>2025-09-15T17:03:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=95d5d984db4092136ad4b178b765516168c31b9e'/>
<id>95d5d984db4092136ad4b178b765516168c31b9e</id>
<content type='text'>
This patch causes the various AST dump commands (`target modules dump
ast`/`target dump typesystem`) to be color-highlighted. I added a `bool
show_color` parameter to `SymbolFile::DumpClangAST` and
`TypeSystem::Dump`. In `TypeSystemClang` I temporarily sets the
`getShowColors` flag on the owned Clang AST (using an RAII helper) for
the duration of the AST dump. We use `Debugger::GetUseColors` to decide
whether to color the AST dump.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch causes the various AST dump commands (`target modules dump
ast`/`target dump typesystem`) to be color-highlighted. I added a `bool
show_color` parameter to `SymbolFile::DumpClangAST` and
`TypeSystem::Dump`. In `TypeSystemClang` I temporarily sets the
`getShowColors` flag on the owned Clang AST (using an RAII helper) for
the duration of the AST dump. We use `Debugger::GetUseColors` to decide
whether to color the AST dump.</pre>
</div>
</content>
</entry>
<entry>
<title>[LLDB][NativePDB] Complete array member types in AST builder (#156370)</title>
<updated>2025-09-02T20:53:44+00:00</updated>
<author>
<name>nerix</name>
<email>nerixdev@outlook.de</email>
</author>
<published>2025-09-02T20:53:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=3c7bf3b3c3a4871d13f7b7d5d60bbf190eaf8f3a'/>
<id>3c7bf3b3c3a4871d13f7b7d5d60bbf190eaf8f3a</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[clang] Improve nested name specifier AST representation (#147835)</title>
<updated>2025-08-09T08:06:53+00:00</updated>
<author>
<name>Matheus Izvekov</name>
<email>mizvekov@gmail.com</email>
</author>
<published>2025-08-09T08:06:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=91cdd35008e9ab32dffb7e401cdd7313b3461892'/>
<id>91cdd35008e9ab32dffb7e401cdd7313b3461892</id>
<content type='text'>
This is a major change on how we represent nested name qualifications in
the AST.

* The nested name specifier itself and how it's stored is changed. The
prefixes for types are handled within the type hierarchy, which makes
canonicalization for them super cheap, no memory allocation required.
Also translating a type into nested name specifier form becomes a no-op.
An identifier is stored as a DependentNameType. The nested name
specifier gains a lightweight handle class, to be used instead of
passing around pointers, which is similar to what is implemented for
TemplateName. There is still one free bit available, and this handle can
be used within a PointerUnion and PointerIntPair, which should keep
bit-packing aficionados happy.
* The ElaboratedType node is removed, all type nodes in which it could
previously apply to can now store the elaborated keyword and name
qualifier, tail allocating when present.
* TagTypes can now point to the exact declaration found when producing
these, as opposed to the previous situation of there only existing one
TagType per entity. This increases the amount of type sugar retained,
and can have several applications, for example in tracking module
ownership, and other tools which care about source file origins, such as
IWYU. These TagTypes are lazily allocated, in order to limit the
increase in AST size.

This patch offers a great performance benefit.

It greatly improves compilation time for
[stdexec](https://github.com/NVIDIA/stdexec). For one datapoint, for
`test_on2.cpp` in that project, which is the slowest compiling test,
this patch improves `-c` compilation time by about 7.2%, with the
`-fsyntax-only` improvement being at ~12%.

This has great results on compile-time-tracker as well:

![image](https://github.com/user-attachments/assets/700dce98-2cab-4aa8-97d1-b038c0bee831)

This patch also further enables other optimziations in the future, and
will reduce the performance impact of template specialization resugaring
when that lands.

It has some other miscelaneous drive-by fixes.

About the review: Yes the patch is huge, sorry about that. Part of the
reason is that I started by the nested name specifier part, before the
ElaboratedType part, but that had a huge performance downside, as
ElaboratedType is a big performance hog. I didn't have the steam to go
back and change the patch after the fact.

There is also a lot of internal API changes, and it made sense to remove
ElaboratedType in one go, versus removing it from one type at a time, as
that would present much more churn to the users. Also, the nested name
specifier having a different API avoids missing changes related to how
prefixes work now, which could make existing code compile but not work.

How to review: The important changes are all in
`clang/include/clang/AST` and `clang/lib/AST`, with also important
changes in `clang/lib/Sema/TreeTransform.h`.

The rest and bulk of the changes are mostly consequences of the changes
in API.

PS: TagType::getDecl is renamed to `getOriginalDecl` in this patch, just
for easier to rebasing. I plan to rename it back after this lands.

Fixes #136624
Fixes https://github.com/llvm/llvm-project/issues/43179
Fixes https://github.com/llvm/llvm-project/issues/68670
Fixes https://github.com/llvm/llvm-project/issues/92757</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is a major change on how we represent nested name qualifications in
the AST.

* The nested name specifier itself and how it's stored is changed. The
prefixes for types are handled within the type hierarchy, which makes
canonicalization for them super cheap, no memory allocation required.
Also translating a type into nested name specifier form becomes a no-op.
An identifier is stored as a DependentNameType. The nested name
specifier gains a lightweight handle class, to be used instead of
passing around pointers, which is similar to what is implemented for
TemplateName. There is still one free bit available, and this handle can
be used within a PointerUnion and PointerIntPair, which should keep
bit-packing aficionados happy.
* The ElaboratedType node is removed, all type nodes in which it could
previously apply to can now store the elaborated keyword and name
qualifier, tail allocating when present.
* TagTypes can now point to the exact declaration found when producing
these, as opposed to the previous situation of there only existing one
TagType per entity. This increases the amount of type sugar retained,
and can have several applications, for example in tracking module
ownership, and other tools which care about source file origins, such as
IWYU. These TagTypes are lazily allocated, in order to limit the
increase in AST size.

This patch offers a great performance benefit.

It greatly improves compilation time for
[stdexec](https://github.com/NVIDIA/stdexec). For one datapoint, for
`test_on2.cpp` in that project, which is the slowest compiling test,
this patch improves `-c` compilation time by about 7.2%, with the
`-fsyntax-only` improvement being at ~12%.

This has great results on compile-time-tracker as well:

![image](https://github.com/user-attachments/assets/700dce98-2cab-4aa8-97d1-b038c0bee831)

This patch also further enables other optimziations in the future, and
will reduce the performance impact of template specialization resugaring
when that lands.

It has some other miscelaneous drive-by fixes.

About the review: Yes the patch is huge, sorry about that. Part of the
reason is that I started by the nested name specifier part, before the
ElaboratedType part, but that had a huge performance downside, as
ElaboratedType is a big performance hog. I didn't have the steam to go
back and change the patch after the fact.

There is also a lot of internal API changes, and it made sense to remove
ElaboratedType in one go, versus removing it from one type at a time, as
that would present much more churn to the users. Also, the nested name
specifier having a different API avoids missing changes related to how
prefixes work now, which could make existing code compile but not work.

How to review: The important changes are all in
`clang/include/clang/AST` and `clang/lib/AST`, with also important
changes in `clang/lib/Sema/TreeTransform.h`.

The rest and bulk of the changes are mostly consequences of the changes
in API.

PS: TagType::getDecl is renamed to `getOriginalDecl` in this patch, just
for easier to rebasing. I plan to rename it back after this lands.

Fixes #136624
Fixes https://github.com/llvm/llvm-project/issues/43179
Fixes https://github.com/llvm/llvm-project/issues/68670
Fixes https://github.com/llvm/llvm-project/issues/92757</pre>
</div>
</content>
</entry>
<entry>
<title>[LLDB][NativePDB] Use undecorated name for types if UniqueName isn't mangled (#152114)</title>
<updated>2025-08-06T02:57:26+00:00</updated>
<author>
<name>nerix</name>
<email>nerixdev@outlook.de</email>
</author>
<published>2025-08-06T02:57:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=2d4e5c4e1f0ee00cc668b5f012d718e750a99cc7'/>
<id>2d4e5c4e1f0ee00cc668b5f012d718e750a99cc7</id>
<content type='text'>
Languages other than C/C++ don't necessarily emit mangled names in the
`UniqueName` field of type records. Rust specifically emits a unique ID
that doesn't contain the name.

For example, `(i32, i32)` is emitted as

```llvm
!266 = !DICompositeType(
  tag: DW_TAG_structure_type, name: "tuple$&lt;i32,i32&gt;", file: !9, size: 64, align: 32,
  elements: !267, templateParams: !17, identifier: "19122721b0632fe96c0dd37477674472"
)
```

which results in

```
  0x1091 | LF_STRUCTURE [size = 72, hash = 0x1AC67] `tuple$&lt;i32,i32&gt;`
           unique name: `19122721b0632fe96c0dd37477674472`
           vtable: &lt;no type&gt;, base list: &lt;no type&gt;, field list: 0x1090
           options: has unique name, sizeof 8
```

In C++ with Clang and MSVC, a structure similar to this would result in
```
   0x136F | LF_STRUCTURE [size = 44, hash = 0x30BE2] `MyTuple`
            unique name: `.?AUMyTuple@@`
            vtable: &lt;no type&gt;, base list: &lt;no type&gt;, field list: 0x136E
            options: has unique name, sizeof 8
```

With this PR, if a `UniqueName` is encountered that couldn't be parsed,
it will fall back to using the undecorated (→ do the same as if the
unique name is empty/unavailable).

I'm not sure how to test this. Maybe compiling the LLVM IR that rustc
emits?

Fixes #152051.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Languages other than C/C++ don't necessarily emit mangled names in the
`UniqueName` field of type records. Rust specifically emits a unique ID
that doesn't contain the name.

For example, `(i32, i32)` is emitted as

```llvm
!266 = !DICompositeType(
  tag: DW_TAG_structure_type, name: "tuple$&lt;i32,i32&gt;", file: !9, size: 64, align: 32,
  elements: !267, templateParams: !17, identifier: "19122721b0632fe96c0dd37477674472"
)
```

which results in

```
  0x1091 | LF_STRUCTURE [size = 72, hash = 0x1AC67] `tuple$&lt;i32,i32&gt;`
           unique name: `19122721b0632fe96c0dd37477674472`
           vtable: &lt;no type&gt;, base list: &lt;no type&gt;, field list: 0x1090
           options: has unique name, sizeof 8
```

In C++ with Clang and MSVC, a structure similar to this would result in
```
   0x136F | LF_STRUCTURE [size = 44, hash = 0x30BE2] `MyTuple`
            unique name: `.?AUMyTuple@@`
            vtable: &lt;no type&gt;, base list: &lt;no type&gt;, field list: 0x136E
            options: has unique name, sizeof 8
```

With this PR, if a `UniqueName` is encountered that couldn't be parsed,
it will fall back to using the undecorated (→ do the same as if the
unique name is empty/unavailable).

I'm not sure how to test this. Maybe compiling the LLVM IR that rustc
emits?

Fixes #152051.</pre>
</div>
</content>
</entry>
<entry>
<title>[LLDB][NativePDB] Implement `FindNamespace` (#151950)</title>
<updated>2025-08-05T10:10:27+00:00</updated>
<author>
<name>nerix</name>
<email>nerixdev@outlook.de</email>
</author>
<published>2025-08-05T10:10:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=852cc9200f7c7cc76bc61ac2aa42712c94793f0d'/>
<id>852cc9200f7c7cc76bc61ac2aa42712c94793f0d</id>
<content type='text'>
`FindNamespace` was not implemented for `SymbolFileNativePDB`. Without
it, it wasn't possible to lookup items through namespaces when
evaluating expressions.

This is mostly the same as in
[SymbolFilePDB](https://github.com/llvm/llvm-project/blob/f1eb869bae2ab86726ee3a5a5c7980d5b2acbd5d/lldb/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp#L1664-L1696)
as well as
[PDBAstParser](https://github.com/llvm/llvm-project/blob/f1eb869bae2ab86726ee3a5a5c7980d5b2acbd5d/lldb/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp#L1126-L1150):
The AST parser/builder saves the created namespaces in a map to lookup
when a namespace is requested.

This is working towards making
[Shell/SymbolFile/PDB/expressions.test](https://github.com/llvm/llvm-project/blob/f1eb869bae2ab86726ee3a5a5c7980d5b2acbd5d/lldb/test/Shell/SymbolFile/PDB/expressions.test)
pass with the native PDB plugin.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
`FindNamespace` was not implemented for `SymbolFileNativePDB`. Without
it, it wasn't possible to lookup items through namespaces when
evaluating expressions.

This is mostly the same as in
[SymbolFilePDB](https://github.com/llvm/llvm-project/blob/f1eb869bae2ab86726ee3a5a5c7980d5b2acbd5d/lldb/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp#L1664-L1696)
as well as
[PDBAstParser](https://github.com/llvm/llvm-project/blob/f1eb869bae2ab86726ee3a5a5c7980d5b2acbd5d/lldb/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp#L1126-L1150):
The AST parser/builder saves the created namespaces in a map to lookup
when a namespace is requested.

This is working towards making
[Shell/SymbolFile/PDB/expressions.test](https://github.com/llvm/llvm-project/blob/f1eb869bae2ab86726ee3a5a5c7980d5b2acbd5d/lldb/test/Shell/SymbolFile/PDB/expressions.test)
pass with the native PDB plugin.</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb][TypeSystemClang] Make AsmLabel parameter a llvm::StringRef (#151355)</title>
<updated>2025-07-31T06:11:30+00:00</updated>
<author>
<name>Michael Buch</name>
<email>michaelbuch12@gmail.com</email>
</author>
<published>2025-07-31T06:11:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=7410f6d31de7fded4c0efdc342ab50223d3c7250'/>
<id>7410f6d31de7fded4c0efdc342ab50223d3c7250</id>
<content type='text'>
Split out from https://github.com/llvm/llvm-project/pull/148877

This patch prepares `TypeSystemClang` APIs to take `AsmLabel`s which
concatenated strings (hence `std::string`) instead of a plain `const
char*`.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Split out from https://github.com/llvm/llvm-project/pull/148877

This patch prepares `TypeSystemClang` APIs to take `AsmLabel`s which
concatenated strings (hence `std::string`) instead of a plain `const
char*`.</pre>
</div>
</content>
</entry>
<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>
</feed>
