|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4 |
|
| #
3339000e |
| 12-May-2022 |
Jim Ingham <[email protected]> |
We don't require users to type out the full context of a function, for symbol name matches. Instead, we extract the incoming path's base name, look up all the symbols with that base name, and then co
We don't require users to type out the full context of a function, for symbol name matches. Instead, we extract the incoming path's base name, look up all the symbols with that base name, and then compare the rest of the context that the user provided to make sure it matches. However, we do this comparison using just a strstr. So for instance:
break set -n foo::bar
will match not only "a::foo::bar" but "notherfoo::bar". The former is pretty clearly the user's intent, but I don't think the latter is, and results in breakpoints picking up too many matches.
This change adds a Language::DemangledNameContainsPath API which can do a language aware match against the path provided. If the language doesn't provide this we fall back to the strstr (though that's changed to StringRef::contains in the patch).
Differential Revision: https://reviews.llvm.org/D124579
show more ...
|
|
Revision tags: llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1 |
|
| #
49481b53 |
| 21-Oct-2021 |
Pavel Labath <[email protected]> |
Remove ConstString from Language, LanguageRuntime, SystemRuntime and SymbolFile plugin names
|
| #
a3939e15 |
| 15-Oct-2021 |
Pavel Labath <[email protected]> |
[lldb] Return StringRef from PluginInterface::GetPluginName
There is no reason why this function should be returning a ConstString.
While modifying these files, I also fixed several instances where
[lldb] Return StringRef from PluginInterface::GetPluginName
There is no reason why this function should be returning a ConstString.
While modifying these files, I also fixed several instances where GetPluginName and GetPluginNameStatic were returning different strings.
I am not changing the return type of GetPluginNameStatic in this patch, as that would necessitate additional changes, and this patch is big enough as it is.
Differential Revision: https://reviews.llvm.org/D111877
show more ...
|
|
Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4 |
|
| #
385b2189 |
| 20-Sep-2021 |
Alex Langford <[email protected]> |
[lldb] Remove Expression's dependency on CPlusPlusLanguagePlugin
This change accomplishes the following: - Moves `IRExecutionUnit::FindBestAlternateMangledName` to `Language`. - Renames `FindBestAlt
[lldb] Remove Expression's dependency on CPlusPlusLanguagePlugin
This change accomplishes the following: - Moves `IRExecutionUnit::FindBestAlternateMangledName` to `Language`. - Renames `FindBestAlternateMangledName` to `FindBestAlternateFunctionMangledName` - Changes the first parameter of said method from a `ConstString` representing a demangled name to a `Mangled`. - Remove the use of CPlusPlusLanguage from Expression
show more ...
|
| #
a65f6aaf |
| 14-Sep-2021 |
Alex Langford <[email protected]> |
[lldb] Refactor and rename CPlusPlusLanguage::FindAlternateFunctionManglings
I have 2 goals with this change: 1. Disambiguate between CPlusPlus::FindAlternateFunctionManglings and IRExecutionUnit
[lldb] Refactor and rename CPlusPlusLanguage::FindAlternateFunctionManglings
I have 2 goals with this change: 1. Disambiguate between CPlusPlus::FindAlternateFunctionManglings and IRExecutionUnit::FindBestAlternateMangledName. These are named very similar things, they try to do very similar things, but their approaches are different. This change should make it clear that one is generating possible alternate manglings (through some heuristics-based approach) and the other is finding alternate manglings (through searching the SymbolFile for potential matches). 2. Change GenerateAlternateFunctionManglings from a static method in CPlusPlusLanguage to a virtual method in Language. This will allow us to remove a direct use of CPlusPlusLanguage in IRExecutionUnit, further pushing it to be more general. This change doesn't meet this goal completely but allows for it to happen later.
Though this doesn't remove IRExecutionUnit's dependency on CPlusPlusLanguage, it does bring us closer to that goal.
Differential Revision: https://reviews.llvm.org/D109785
show more ...
|
|
Revision tags: llvmorg-13.0.0-rc3 |
|
| #
b0312676 |
| 10-Sep-2021 |
Pavel Labath <[email protected]> |
[lldb] Remove PluginInterface::GetPluginVersion
In all these years, we haven't found a use for this function (it has zero callers). Lets just remove the boilerplate.
Differential Revision: https://
[lldb] Remove PluginInterface::GetPluginVersion
In all these years, we haven't found a use for this function (it has zero callers). Lets just remove the boilerplate.
Differential Revision: https://reviews.llvm.org/D109600
show more ...
|
|
Revision tags: llvmorg-13.0.0-rc2 |
|
| #
ce512d5c |
| 24-Aug-2021 |
Alex Langford <[email protected]> |
Revert "[lldb] Refactor Module::LookupInfo constructor"
This reverts commit cd2134e42aa7d1168a3ed54e41793b022f961b1f.
Seems like this broke some tests on arm and aarch64 boxes. Will investigate bef
Revert "[lldb] Refactor Module::LookupInfo constructor"
This reverts commit cd2134e42aa7d1168a3ed54e41793b022f961b1f.
Seems like this broke some tests on arm and aarch64 boxes. Will investigate before re-landing.
show more ...
|
| #
cd2134e4 |
| 17-Aug-2021 |
Alex Langford <[email protected]> |
[lldb] Refactor Module::LookupInfo constructor
Module::LookupInfo's constructor currently goes over supported languages trying to figure out the best way to search for a symbol name. This seems like
[lldb] Refactor Module::LookupInfo constructor
Module::LookupInfo's constructor currently goes over supported languages trying to figure out the best way to search for a symbol name. This seems like a great candidate for refactoring. Specifically, this is work that can be delegated to language plugins.
Once again, the goal here is to further decouple plugins from non-plugins. The idea is to have each language plugin take a name and give you back some information about the name from the perspective of the language. Specifically, each language now implements a `GetFunctionNameInfo` method which returns an object of type `Language::FunctionNameInfo`. Right now, it consists of a basename, a context, and a FunctionNameType. Module::LookupInfo's constructor will call `GetFunctionNameInfo` with the appropriate language plugin(s) and then decide what to do with that information. I have attempted to maintain existing behavior as best as possible.
A nice side effect of this change is that lldbCore no longer links against the ObjC Language plugin.
Differential Revision: https://reviews.llvm.org/D108229
show more ...
|
|
Revision tags: llvmorg-13.0.0-rc1, llvmorg-14-init |
|
| #
993220a9 |
| 29-Jun-2021 |
Alex Langford <[email protected]> |
[lldb] Remove CPlusPlusLanguage from Mangled
The only remaining plugin dependency in Mangled is CPlusPlusLanguage which it uses to extract information from C++ mangled names. The static function Get
[lldb] Remove CPlusPlusLanguage from Mangled
The only remaining plugin dependency in Mangled is CPlusPlusLanguage which it uses to extract information from C++ mangled names. The static function GetDemangledNameWithoutArguments is written specifically for C++, so it would make sense for this specific functionality to live in a C++-related plugin. In order to keep this functionality in Mangled without maintaining this dependency, I added `Language::GetDemangledFunctionNameWithoutArguments`.
Differential Revision: https://reviews.llvm.org/D105215
show more ...
|
|
Revision tags: llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2 |
|
| #
9494c510 |
| 09-Jun-2021 |
Jonas Devlieghere <[email protected]> |
[lldb] Use C++11 default member initializers
This converts a default constructor's member initializers into C++11 default member initializers. This patch was automatically generated with clang-tidy
[lldb] Use C++11 default member initializers
This converts a default constructor's member initializers into C++11 default member initializers. This patch was automatically generated with clang-tidy and the modernize-use-default-member-init check.
$ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-default-member-init' -fix
This is a mass-refactoring patch and this commit will be added to .git-blame-ignore-revs.
Differential revision: https://reviews.llvm.org/D103483
show more ...
|
| #
ecfca427 |
| 01-Jun-2021 |
Raphael Isemann <[email protected]> |
[lldb][NFC] Use Language plugins in Mangled::GuessLanguage
This removes the direct dependency to the ObjC and C++ plugins.
Reviewed By: bulbazord
Differential Revision: https://reviews.llvm.org/D1
[lldb][NFC] Use Language plugins in Mangled::GuessLanguage
This removes the direct dependency to the ObjC and C++ plugins.
Reviewed By: bulbazord
Differential Revision: https://reviews.llvm.org/D103158
show more ...
|
|
Revision tags: llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1 |
|
| #
406ad187 |
| 12-Nov-2020 |
Jonas Devlieghere <[email protected]> |
[lldb/DataFormatters] Display null C++ pointers as nullptr
Display null pointer as `nullptr`, `nil` and `NULL` for C++, Objective-C/Objective-C++ and C respectively. The original motivation for this
[lldb/DataFormatters] Display null C++ pointers as nullptr
Display null pointer as `nullptr`, `nil` and `NULL` for C++, Objective-C/Objective-C++ and C respectively. The original motivation for this patch was to display a null std::string pointer as nullptr instead of "", but the fix seemed generic enough to be done for all summary providers.
Differential revision: https://reviews.llvm.org/D77153
show more ...
|
|
Revision tags: llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3 |
|
| #
cdc514e4 |
| 17-Feb-2020 |
Jonas Devlieghere <[email protected]> |
[lldb] Update header guards to be consistent and compliant with LLVM (NFC)
LLDB has a few different styles of header guards and they're not very consistent because things get moved around or copy/pa
[lldb] Update header guards to be consistent and compliant with LLVM (NFC)
LLDB has a few different styles of header guards and they're not very consistent because things get moved around or copy/pasted. This patch unifies the header guards across LLDB and converts everything to match LLVM's style.
Differential revision: https://reviews.llvm.org/D74743
show more ...
|
|
Revision tags: llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1 |
|
| #
83393d27 |
| 06-Nov-2019 |
shafik <[email protected]> |
[LLDB] Fix handling for the clang name mangling extension for block invocations
Add support for clangs mangling extension for block invocations.
Differential Revision: https://reviews.llvm.org/D69
[LLDB] Fix handling for the clang name mangling extension for block invocations
Add support for clangs mangling extension for block invocations.
Differential Revision: https://reviews.llvm.org/D69738
show more ...
|
|
Revision tags: llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1 |
|
| #
8b3af63b |
| 10-Apr-2019 |
Jonas Devlieghere <[email protected]> |
[NFC] Remove ASCII lines from comments
A lot of comments in LLDB are surrounded by an ASCII line to delimit the begging and end of the comment.
Its use is not really consistent across the code base
[NFC] Remove ASCII lines from comments
A lot of comments in LLDB are surrounded by an ASCII line to delimit the begging and end of the comment.
Its use is not really consistent across the code base, sometimes the lines are longer, sometimes they are shorter and sometimes they are omitted. Furthermore, it looks kind of weird with the 80 column limit, where the comment actually extends past the line, but not by much. Furthermore, when /// is used for Doxygen comments, it looks particularly odd. And when // is used, it incorrectly gives the impression that it's actually a Doxygen comment.
I assume these lines were added to improve distinguishing between comments and code. However, given that todays editors and IDEs do a great job at highlighting comments, I think it's worth to drop this for the sake of consistency. The alternative is fixing all the inconsistencies, which would create a lot more churn.
Differential revision: https://reviews.llvm.org/D60508
llvm-svn: 358135
show more ...
|
|
Revision tags: llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4 |
|
| #
0e4c4821 |
| 06-Mar-2019 |
Adrian Prantl <[email protected]> |
Pass ConstString by value (NFC)
My apologies for the large patch. With the exception of ConstString.h itself it was entirely produced by sed.
ConstString has exactly one const char * data member, s
Pass ConstString by value (NFC)
My apologies for the large patch. With the exception of ConstString.h itself it was entirely produced by sed.
ConstString has exactly one const char * data member, so passing a ConstString by reference is not any more efficient than copying it by value. In both cases a single pointer is passed. But passing it by value makes it harder to accidentally return the address of a local object.
(This fixes rdar://problem/48640859 for the Apple folks)
Differential Revision: https://reviews.llvm.org/D59030
llvm-svn: 355553
show more ...
|
|
Revision tags: llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1 |
|
| #
2946cd70 |
| 19-Jan-2019 |
Chandler Carruth <[email protected]> |
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the ne
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository.
llvm-svn: 351636
show more ...
|
|
Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3 |
|
| #
ceff6644 |
| 11-Nov-2018 |
Jonas Devlieghere <[email protected]> |
Remove header grouping comments.
This patch removes the comments grouping header includes. They were added after running IWYU over the LLDB codebase. However they add little value, are often outdate
Remove header grouping comments.
This patch removes the comments grouping header includes. They were added after running IWYU over the LLDB codebase. However they add little value, are often outdates and burdensome to maintain.
llvm-svn: 346626
show more ...
|
|
Revision tags: llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1, llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2, llvmorg-7.0.0-rc1 |
|
| #
566afa0a |
| 02-Aug-2018 |
Raphael Isemann <[email protected]> |
[LLDB] Added syntax highlighting support
Summary: This patch adds syntax highlighting support to LLDB. When enabled (and lldb is allowed to use colors), printed source code is annotated with the ANS
[LLDB] Added syntax highlighting support
Summary: This patch adds syntax highlighting support to LLDB. When enabled (and lldb is allowed to use colors), printed source code is annotated with the ANSI color escape sequences.
So far we have only one highlighter which is based on Clang and is responsible for all languages that are supported by Clang. It essentially just runs the raw lexer over the input and then surrounds the specific tokens with the configured escape sequences.
Reviewers: zturner, davide
Reviewed By: davide
Subscribers: labath, teemperor, llvm-commits, mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D49334
llvm-svn: 338662
show more ...
|
|
Revision tags: llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2, llvmorg-6.0.1-rc1, llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1, llvmorg-6.0.0, llvmorg-6.0.0-rc3, llvmorg-6.0.0-rc2, llvmorg-6.0.0-rc1, llvmorg-5.0.1, llvmorg-5.0.1-rc3, llvmorg-5.0.1-rc2, llvmorg-5.0.1-rc1, llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3, llvmorg-5.0.0-rc2, llvmorg-5.0.0-rc1, llvmorg-4.0.1, llvmorg-4.0.1-rc3, llvmorg-4.0.1-rc2 |
|
| #
a193a4c8 |
| 02-May-2017 |
Pavel Labath <[email protected]> |
Remove unused code related to CPlusPlusLanguage::FindEquivalentNames
Summary: It is simply unused, and the header for it is private, so there should be no external dependencies.
Reviewers: #lldb, z
Remove unused code related to CPlusPlusLanguage::FindEquivalentNames
Summary: It is simply unused, and the header for it is private, so there should be no external dependencies.
Reviewers: #lldb, zturner
Reviewed By: zturner
Subscribers: zturner, tberghammer, jingham, lldb-commits
Differential Revision: https://reviews.llvm.org/D32503 Patch by Scott Smith <[email protected]>.
llvm-svn: 301903
show more ...
|
|
Revision tags: llvmorg-4.0.1-rc1 |
|
| #
a633ee6e |
| 06-Apr-2017 |
Eugene Zemtsov <[email protected]> |
New C++ function name parsing logic (Resubmit)
Current implementation of CPlusPlusLanguage::MethodName::Parse() doesn't get anywhere close to covering full extent of possible function declarations.
New C++ function name parsing logic (Resubmit)
Current implementation of CPlusPlusLanguage::MethodName::Parse() doesn't get anywhere close to covering full extent of possible function declarations. It causes incorrect behavior in avoid-stepping and sometimes messes printing of thread backtrace.
This change implements more methodical parsing logic based on clang lexer and simple recursive parser.
Examples: void std::vector<Class, std::allocator<Class>>::_M_emplace_back_aux<Class const&>(Class const&) void (*&std::_Any_data::_M_access<void (*)()>())()
Previous version of this change (D31451) was rolled back due to an issue with Objective-C selectors being incorrectly recognized as a C++ identifier.
Differential Revision: https://reviews.llvm.org/D31451
llvm-svn: 299721
show more ...
|
| #
9645a629 |
| 05-Apr-2017 |
Jim Ingham <[email protected]> |
Reverting r299374 & r299402 due to testsuite failure.
This caused a failure in the test case:
functionalities/breakpoint/objc/TestObjCBreakpoints.py
When we are parsing up names we stick interes
Reverting r299374 & r299402 due to testsuite failure.
This caused a failure in the test case:
functionalities/breakpoint/objc/TestObjCBreakpoints.py
When we are parsing up names we stick interesting parts of the names in various buckets, one of which is the ObjC selector bucket. The new C++ name parser must be interfering with this process somehow.
<rdar://problem/31439305>
llvm-svn: 299489
show more ...
|
| #
699a7488 |
| 03-Apr-2017 |
Eugene Zemtsov <[email protected]> |
New C++ function name parsing logic
Current implementation of CPlusPlusLanguage::MethodName::Parse() doesn't get anywhere close to covering full extent of possible function declarations. It causes i
New C++ function name parsing logic
Current implementation of CPlusPlusLanguage::MethodName::Parse() doesn't get anywhere close to covering full extent of possible function declarations. It causes incorrect behavior in avoid-stepping and sometimes messes printing of thread backtrace.
This change implements more methodical parsing logic based on clang lexer and simple recursive parser.
Examples: void std::vector<Class, std::allocator<Class>>::_M_emplace_back_aux<Class const&>(Class const&) void (*&std::_Any_data::_M_access<void (*)()>())()
Differential Revision: https://reviews.llvm.org/D31451
llvm-svn: 299374
show more ...
|
|
Revision tags: llvmorg-4.0.0, llvmorg-4.0.0-rc4, llvmorg-4.0.0-rc3, llvmorg-4.0.0-rc2 |
|
| #
bf9a7730 |
| 02-Feb-2017 |
Zachary Turner <[email protected]> |
Move classes from Core -> Utility.
This moves the following classes from Core -> Utility.
ConstString Error RegularExpression Stream StreamString
The goal here is to get lldbUtility into a state w
Move classes from Core -> Utility.
This moves the following classes from Core -> Utility.
ConstString Error RegularExpression Stream StreamString
The goal here is to get lldbUtility into a state where it has no dependendencies except on itself and LLVM, so it can be the starting point at which to start untangling LLDB's dependencies. These are all low level and very widely used classes, and previously lldbUtility had dependencies up to lldbCore in order to use these classes. So moving then down to lldbUtility makes sense from both the short term and long term perspective in solving this problem.
Differential Revision: https://reviews.llvm.org/D29427
llvm-svn: 293941
show more ...
|
|
Revision tags: llvmorg-4.0.0-rc1 |
|
| #
f5bb1d6c |
| 19-Dec-2016 |
Luke Drummond <[email protected]> |
Expression evaluation for overloaded C functions (redux)
This is a redux of [Ewan's patch](https://reviews.llvm.org/D17957) , refactored to properly substitute primitive types using a hook in the i
Expression evaluation for overloaded C functions (redux)
This is a redux of [Ewan's patch](https://reviews.llvm.org/D17957) , refactored to properly substitute primitive types using a hook in the itanium demangler, and updated after the previous patch went stale
The new `SubsPrimitiveParmItanium` function takes a symbol name and replacement primitive type parameter as before but parses it using the FastDemangler, which has been modified to be able to notify clients of parse events (primitive types at this point).
Additionally, we now use a `set` of `ConstStrings` instead of a `vector` so that we don't try and resolve the same invalid candidate multiple times.
Differential Revision: https://reviews.llvm.org/D27223 Subscribers: lldb-commits
llvm-svn: 290117
show more ...
|