|
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, 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, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, 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, 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 |
|
| #
b58af8d2 |
| 27-Apr-2020 |
Raphael Isemann <[email protected]> |
[lldb] Improve error message when --func-regex parameter for the breakpoint command is invalid
Summary: Currently the breakpoint command is prompting the user to file a bug report if the provided re
[lldb] Improve error message when --func-regex parameter for the breakpoint command is invalid
Summary: Currently the breakpoint command is prompting the user to file a bug report if the provided regex is invalid: ``` (lldb) rbreak *foo error: Function name regular expression could not be compiled: "Inconvertible error value. An error has occurred that could not be converted to a known std::error_code. Please file a bug. repetition-operator operand invalid" ```
The reason is simply that we are using the wrong StringError constructor (the one with the error code as the first parameter is also printing the string version of the error code, and the inconvertible error code is just an invalid place holder code with that description). Switching the StringError constructor parameters will only print the error message we get from the regex engine when we convert the error into a string.
I checked the rest of the code base and I couldn't find the same issue anywhere else.
Fixes rdar://62233561
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D78808
show more ...
|
|
Revision tags: llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1 |
|
| #
adcd0268 |
| 28-Jan-2020 |
Benjamin Kramer <[email protected]> |
Make llvm::StringRef to std::string conversions explicit.
This is how it should've been and brings it more in line with std::string_view. There should be no functional change here.
This is mostly m
Make llvm::StringRef to std::string conversions explicit.
This is how it should've been and brings it more in line with std::string_view. There should be no functional change here.
This is mostly mechanical from a custom clang-tidy check, with a lot of manual fixups. It uncovers a lot of minor inefficiencies.
This doesn't actually modify StringRef yet, I'll do that in a follow-up.
show more ...
|
| #
80814287 |
| 24-Jan-2020 |
Raphael Isemann <[email protected]> |
[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 ----------------------------------------
[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
show more ...
|
|
Revision tags: llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3 |
|
| #
1c56d3df |
| 20-Aug-2019 |
Jan Kratochvil <[email protected]> |
[lldb] Use the new Regex::isValid() with no parameter
Differential Revision: https://reviews.llvm.org/D66463
llvm-svn: 369398
|
| #
f9d90bc5 |
| 20-Aug-2019 |
Jan Kratochvil <[email protected]> |
[lldb] D66174 `RegularExpression` cleanup
I find as a good cleanup to drop the Compile method. As I do not find TIMTOWTDI as an advantage and there is already constructor parameter to compile the re
[lldb] D66174 `RegularExpression` cleanup
I find as a good cleanup to drop the Compile method. As I do not find TIMTOWTDI as an advantage and there is already constructor parameter to compile the regex.
Differential Revision: https://reviews.llvm.org/D66392
llvm-svn: 369352
show more ...
|
| #
3af3f1e8 |
| 16-Aug-2019 |
Jonas Devlieghere <[email protected]> |
[Utility] Reimplement RegularExpression on top of llvm::Regex
Originally I wanted to remove the RegularExpression class in Utility and replace it with llvm::Regex. However, during that transition I
[Utility] Reimplement RegularExpression on top of llvm::Regex
Originally I wanted to remove the RegularExpression class in Utility and replace it with llvm::Regex. However, during that transition I noticed that there are several places where need the regular expression string. So instead I propose to keep the RegularExpression class and make it a thin wrapper around llvm::Regex.
This patch also removes the workaround for empty regular expressions. The result is that we are now (more or less) POSIX conformant.
Differential revision: https://reviews.llvm.org/D66174
llvm-svn: 369153
show more ...
|
|
Revision tags: llvmorg-9.0.0-rc2 |
|
| #
b78c8a0a |
| 08-Aug-2019 |
Jonas Devlieghere <[email protected]> |
[Utility] Remove unused function 'GetMatchSpanningIndices'
llvm-svn: 368243
|
|
Revision tags: 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 |
|
| #
56d69ef8 |
| 23-May-2019 |
Jorge Gorbe Moya <[email protected]> |
[lldb] Make sure RegularExpression constructors always initialize member variables
The copy constructor of RegularExpression doesn't initialize m_comp_err. This causes an use-of-initialized-value er
[lldb] Make sure RegularExpression constructors always initialize member variables
The copy constructor of RegularExpression doesn't initialize m_comp_err. This causes an use-of-initialized-value error when a RegularExpression is copied: the copy constructor calls Compile, which calls Free to free the existing regex if needed, which in turn reads m_comp_err to check if there's any regex to be freed.
This change calls the default constructor from the other constructors to make sure members are always initialized with sensible values. This also avoids duplicating init logic, like the RegularExpression(llvm:StringRef) constructor does, which is error prone.
Differential Revision: https://reviews.llvm.org/D62334
llvm-svn: 361546
show more ...
|
|
Revision tags: 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, 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, 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, llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2 |
|
| #
05097246 |
| 30-Apr-2018 |
Adrian Prantl <[email protected]> |
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 r
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
show more ...
|
|
Revision tags: 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, llvmorg-4.0.1-rc1 |
|
| #
4479ac15 |
| 06-Apr-2017 |
Zachary Turner <[email protected]> |
iwyu fixes on lldbUtility.
This patch makes adjustments to header file includes in lldbUtility based on recommendations by the iwyu tool (include-what-you-use). The goal here is to make sure that a
iwyu fixes on lldbUtility.
This patch makes adjustments to header file includes in lldbUtility based on recommendations by the iwyu tool (include-what-you-use). The goal here is to make sure that all files include the exact set of headers which are needed for that file only, to eliminate cases of dead includes (e.g. someone deleted some code but forgot to delete the header includes that that code necessitated), and to eliminate the case where header includes are picked up transitively.
llvm-svn: 299676
show more ...
|
|
Revision tags: llvmorg-4.0.0, llvmorg-4.0.0-rc4, llvmorg-4.0.0-rc3 |
|
| #
c4a33951 |
| 20-Feb-2017 |
Pavel Labath <[email protected]> |
Fix a couple of corner cases in NameMatches
Summary: I originally set out to move the NameMatches closer to the relevant function and add some unit tests. However, in the process I've found a couple
Fix a couple of corner cases in NameMatches
Summary: I originally set out to move the NameMatches closer to the relevant function and add some unit tests. However, in the process I've found a couple of bugs in the implementation: - the early exits where not always correct: - (test==pattern) does not mean the match will always suceed because of regular expressions - pattern.empty() does not mean the match will fail because the "" is a valid prefix of any string
So I cleaned up those and added some tests. The only tricky part here was that regcomp() implementation on darwin did not recognise the empty string as a regular expression and returned an REG_EMPTY error instead. The simples fix here seemed to be to replace the empty expression with an equivalent non-empty one.
Reviewers: clayborg, zturner
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D30094
llvm-svn: 295651
show more ...
|
|
Revision tags: 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 ...
|