Commit Graph

20 Commits

Author SHA1 Message Date
Kazu Hirata 343523d040 [lldb] Use std::nullopt instead of None (NFC)
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated.  The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-12-04 16:51:25 -08:00
Michael Buch 76f34ed283 [lldb][CPlusPlus] Introduce CPlusPlusLanguage::MethodName::GetReturnType
This patch adds a way to extract the return type out
of the `CPlusPlusNameParser`. This will be useful
for cases where we want a function's basename *and* the
return type but not the function arguments; this is
currently not possible (the parser either gives us the
full name or just the basename). Since the parser knows
how to handle return types already we should just expose
this to users that need it.

**Testing**

* Added unit-tests

Differential Revision: https://reviews.llvm.org/D136935
2022-10-31 12:25:18 +00:00
Michael Buch 3cc9884500 [lldb][CPlusPlus] Add abi_tag support to the CPlusPlusNameParser
This patch teaches the `CPlusPlusNameParser` to parse the
demangled/prettified [[gnu::abi_tag(...)]] attribute. The demangled format
isn't standardized and the additions to the parser were mainly driven
using Clang (and the limited information on this from the official
Clang docs).

This change is motivated by multiple failures around step-in
behaviour for libcxx APIs (many of which have ABI tags as of recently).
LLDB determines whether the `step-avoid-regexp` matches the current
frame by parsing the scope-qualified name out of the demangled
function symbol. On failure, the `CPlusPlusNameParser` will simply
return the fully demangled name (which can include the return type)
to the caller, which in `FrameMatchesAvoidCriteria` means we will
not correctly decide whether we should stop at a frame or not if
the function has an abi_tag.

Ideally we wouldn't want to rely on the non-standard format
of demangled attributes. Alternatives would be:

1. Use the mangle tree API to do the parsing for us
2. Reconstruct the scope-qualified name from DWARF instead of parsing
   the demangled name

(1) isn't feasible without a significant refactor of `lldb_private::Mangled`,
if we want to do this efficiently.

(2) could be feasible in cases where debug-info for a frame is
available. But it does mean we certain operations (such as step-in regexp,
and frame function names) won't work with/won't show ABI tags.

**Testing**

* Un-XFAILed step-in API test
* Added parser unit-tests

Differential Revision: https://reviews.llvm.org/D136306
2022-10-21 14:00:50 +01:00
Michael Buch a4561d9348 [lldb][CPlusPlusLanguage] Respect the step-avoid-regex for functions with auto return types
**Summary**

The primary motivation for this patch is to make sure we handle
the step-in behaviour for functions in the `std` namespace which
have an `auto` return type. Currently the default `step-avoid-regex`
setting is `^std::` but LLDB will still step into template functions
with `auto` return types in the `std` namespace.

**Details**
When we hit a breakpoint and check whether we should stop, we call
into `ThreadPlanStepInRange::FrameMatchesAvoidCriteria`. We then ask
for the frame function name via `SymbolContext::GetFunctionName(Mangled::ePreferDemangledWithoutArguments)`.
This ends up trying to parse the function name using `CPlusPlusLanguage::MethodName::GetBasename` which
parses the raw demangled name string.

`CPlusPlusNameParser::ParseFunctionImpl` calls `ConsumeTypename` to skip
the (in our case auto) return type of the demangled name (according to the
Itanium ABI this is a valid thing to encode into the mangled name). However,
`ConsumeTypename` doesn't strip out a plain `auto` identifier
(it will strip a `decltype(auto) return type though). So we are now left with
a basename that still has the return type in it, thus failing to match the `^std::`
regex.

Example frame where the return type is still part of the function name:
```
Process 1234 stopped
* thread #1, stop reason = step in
    frame #0: 0x12345678 repro`auto std::test_return_auto<int>() at main.cpp:12:5
   9
   10   template <class>
   11   auto test_return_auto() {
-> 12       return 42;
   13   }
```

This is another case where the `CPlusPlusNameParser` breaks us in subtle ways
due to evolving C++ syntax. There are longer-term plans of replacing the hand-rolled
C++ parser with an alternative that uses the mangle tree API to do the parsing for us.

**Testing**

* Added API and unit-tests
* Adding support for ABI tags into the parser is a larger undertaking
  which we would rather solve properly by using libcxxabi's mangle tree
  parser

Differential Revision: https://reviews.llvm.org/D135413
2022-10-10 12:50:15 +01:00
Kazu Hirata 258531b7ac Remove redundant initialization of Optional (NFC) 2022-08-20 21:18:28 -07:00
Kazu Hirata 5cff5142a8 Use value instead of getValue (NFC) 2022-07-15 20:03:13 -07:00
Kazu Hirata 3b7c3a654c Revert "Don't use Optional::hasValue (NFC)"
This reverts commit aa8feeefd3.
2022-06-25 11:56:50 -07:00
Kazu Hirata aa8feeefd3 Don't use Optional::hasValue (NFC) 2022-06-25 11:55:57 -07:00
Benjamin Kramer 3806b38045 [LLDB] Initialize temporary token
Found by msan.
2020-03-30 16:12:50 +02:00
shafik 8016d61e3c [LLDB] CPlusPlusNameParser does not handles templated operator< properly
CPlusPlusNameParser is used in several places on of them is during IR execution and setting breakpoints to pull information C++ like the basename, the context and arguments.

Currently it does not handle templated operator< properly, because of idiosyncrasy is how clang generates debug info for these cases.

It uses clang::Lexer which will tokenize operator<<A::B> into:

tok::kw_operator
tok::lessless
tok::raw_identifier

Later on the parser in ConsumeOperator() does not handle this case properly and we end up failing to parse.

Differential Revision: https://reviews.llvm.org/D76168
2020-03-27 14:46:39 -07:00
Raphael Isemann 808142876c [lldb][NFC] Fix all formatting errors in .cpp file headers
Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).

This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).

Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D73258
2020-01-24 08:52:55 +01:00
Adrian Prantl 4a585a3edd Make CPlusPlusNameParser robust against nullptr StringRefs.
There is likely also an underlying bug in all code that calls
CPlusPlusNameParser with nullptrs, but this patch can also stand for
itself.

rdar://problem/49072829

llvm-svn: 362177
2019-05-31 00:18:42 +00:00
Chandler Carruth 2946cd7010 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
2019-01-19 08:50:56 +00:00
Adrian Prantl 05097246f3 Reflow paragraphs in comments.
This is intended as a clean up after the big clang-format commit
(r280751), which unfortunately resulted in many of the comment
paragraphs in LLDB being very hard to read.

FYI, the script I used was:

import textwrap
import commands
import os
import sys
import re
tmp = "%s.tmp"%sys.argv[1]
out = open(tmp, "w+")
with open(sys.argv[1], "r") as f:
  header = ""
  text = ""
  comment = re.compile(r'^( *//) ([^ ].*)$')
  special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$')
  for line in f:
      match = comment.match(line)
      if match and not special.match(match.group(2)):
          # skip intentionally short comments.
          if not text and len(match.group(2)) < 40:
              out.write(line)
              continue

          if text:
              text += " " + match.group(2)
          else:
              header = match.group(1)
              text = match.group(2)

          continue

      if text:
          filled = textwrap.wrap(text, width=(78-len(header)),
                                 break_long_words=False)
          for l in filled:
              out.write(header+" "+l+'\n')
              text = ""

      out.write(line)

os.rename(tmp, sys.argv[1])

Differential Revision: https://reviews.llvm.org/D46144

llvm-svn: 331197
2018-04-30 16:49:04 +00:00
Eugene Zemtsov 9e916e5e0e More correct handling of error cases C++ name parser
Now incorrect type argument that looks like T<A><B> doesn't
cause an assert, but just a parsing error.

Bug: 36224
Differential Revision: https://reviews.llvm.org/D42939

llvm-svn: 324380
2018-02-06 19:04:12 +00:00
Aaron Ballman 05b618e31f Switch from C++1z to C++17; corresponds to r319688 in Clang.
llvm-svn: 319694
2017-12-04 20:46:43 +00:00
Jim Ingham 055e65f0d4 Enable parsing C++ names generated by lambda functions.
https://reviews.llvm.org/D34911 from Weng Xuetian.

llvm-svn: 307944
2017-07-13 19:48:43 +00:00
Eugene Zemtsov a633ee6e4a 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
2017-04-06 22:36:02 +00:00
Jim Ingham 9645a6290a 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
2017-04-05 00:08:21 +00:00
Eugene Zemtsov 699a748893 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
2017-04-03 18:59:34 +00:00