Revision tags: 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 |
|
#
039cfe81 |
| 05-Aug-2024 |
Med Ismail Bennani <ismail@bennani.ma> |
[lldb/Target] Rename ThreadPlanPython into ScriptedThreadPlan (#101931)
Following 9a9ec228cdcf, since the ThreadPlanPython class started making
use of the Scripted Interface instead of calling dire
[lldb/Target] Rename ThreadPlanPython into ScriptedThreadPlan (#101931)
Following 9a9ec228cdcf, since the ThreadPlanPython class started making
use of the Scripted Interface instead of calling directly into the
python methods, this class can work with other scripting languages (as
long as someone add the interfact for that language ;p).
So it doesn't make sense anymore for it to keep this name and also we
should avoid having language specific related classes outside the plugin
directory.
This patch renames the internal class from `ThreadPlanPython` to
`ScriptedThreadPlan` as its advertised externally, and also updates the
various log messages.
This should hopefully make the codebase more coherent.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
show more ...
|
Revision tags: 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 |
|
#
f2d32ddc |
| 09-Aug-2023 |
Alex Langford <alangford@apple.com> |
[lldb] Sink StreamFile into lldbHost
StreamFile subclasses Stream (from lldbUtility) and is backed by a File (from lldbHost). It does not depend on anything from lldbCore or any of its sibling libra
[lldb] Sink StreamFile into lldbHost
StreamFile subclasses Stream (from lldbUtility) and is backed by a File (from lldbHost). It does not depend on anything from lldbCore or any of its sibling libraries, so I think it makes sense for this to live in lldbHost instead.
Differential Revision: https://reviews.llvm.org/D157460
show more ...
|
Revision tags: 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, working, 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 |
|
#
1755f5b1 |
| 19-Jan-2022 |
Jonas Devlieghere <jonas@devlieghere.com> |
[lldb] Decouple instrumentation from the reproducers
Remove the last remaining references to the reproducers from the instrumentation. This patch renames the relevant files and macros.
Differential
[lldb] Decouple instrumentation from the reproducers
Remove the last remaining references to the reproducers from the instrumentation. This patch renames the relevant files and macros.
Differential revision: https://reviews.llvm.org/D117712
show more ...
|
Revision tags: llvmorg-13.0.1-rc2 |
|
#
d232abc3 |
| 10-Jan-2022 |
Jonas Devlieghere <jonas@devlieghere.com> |
[lldb] Remove LLDB_RECORD_RESULT macro
|
#
d51402ac |
| 08-Jan-2022 |
Jonas Devlieghere <jonas@devlieghere.com> |
[lldb] Remove reproducer instrumentation
This patch removes most of the reproducer instrumentation. It keeps around the LLDB_RECORD_* macros for logging. See [1] for more details.
[1] https://lists
[lldb] Remove reproducer instrumentation
This patch removes most of the reproducer instrumentation. It keeps around the LLDB_RECORD_* macros for logging. See [1] for more details.
[1] https://lists.llvm.org/pipermail/lldb-dev/2021-September/017045.html
Differential revision: https://reviews.llvm.org/D116847
show more ...
|
#
82de8df2 |
| 25-Nov-2021 |
Pavel Labath <pavel@labath.sk> |
[lldb] Clarify StructuredDataImpl ownership
StructuredDataImpl ownership semantics is unclear at best. Various structures were holding a non-owning pointer to it, with a comment that the object is o
[lldb] Clarify StructuredDataImpl ownership
StructuredDataImpl ownership semantics is unclear at best. Various structures were holding a non-owning pointer to it, with a comment that the object is owned somewhere else. From what I was able to gather that "somewhere else" was the SBStructuredData object, but I am not sure that all created object eventually made its way there. (It wouldn't matter even if they did, as we are leaking most of our SBStructuredData objects.)
Since StructuredDataImpl is just a collection of two (shared) pointers, there's really no point in elaborate lifetime management, so this patch replaces all StructuredDataImpl pointers with actual objects or unique_ptrs to it. This makes it much easier to resolve SBStructuredData leaks in a follow-up patch.
Differential Revision: https://reviews.llvm.org/D114791
show more ...
|
Revision tags: 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 |
|
#
d3dfd8ce |
| 07-Aug-2020 |
Jim Ingham <jingham@apple.com> |
Add a setting to force stepping to always run all threads. Also allow ScriptedThreadPlans to set & get their StopOthers state.
<rdar://problem/64229484>
Differential Revision: https://reviews.llvm.
Add a setting to force stepping to always run all threads. Also allow ScriptedThreadPlans to set & get their StopOthers state.
<rdar://problem/64229484>
Differential Revision: https://reviews.llvm.org/D85265
show more ...
|
Revision tags: llvmorg-11.0.0-rc1 |
|
#
2ba7ce40 |
| 20-Jul-2020 |
Jonas Devlieghere <jonas@devlieghere.com> |
[lldb] Use weak_ptr to hold on to the underlying thread plan in SBThreadPlan
Use a weak pointer to hold on to the the underlying thread plan in SBThreadPlan. When the process continues, all the popp
[lldb] Use weak_ptr to hold on to the underlying thread plan in SBThreadPlan
Use a weak pointer to hold on to the the underlying thread plan in SBThreadPlan. When the process continues, all the popped ThreadPlans get discarded, and you can’t reuse them, so you have to create them anew. Therefore the SBThreadPlan doesn’t need to keep the ThreadPlan alive.
This fixes the cleanup error in TestThreadPlanCommands.py and TestStepScripted.py caused by the thread plans never being deleted.
Differential revision: https://reviews.llvm.org/D84210
show more ...
|
Revision tags: 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 |
|
#
f7de4b5d |
| 10-Apr-2020 |
Jim Ingham <jingham@apple.com> |
Thread Plans pushed by a scripted plan should be private plans.
If a plan is not private, "thread plan discard" can discard it. It would not be hard to write reliable scripted plan if its subplans
Thread Plans pushed by a scripted plan should be private plans.
If a plan is not private, "thread plan discard" can discard it. It would not be hard to write reliable scripted plan if its subplans could get removed out from under it.
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 |
|
#
866b7a65 |
| 18-Feb-2020 |
Jonas Devlieghere <jonas@devlieghere.com> |
[lldb] Replace empty ctor en dtor bodies with =default (NFC)
Use = default instead of empty constructor and destructor bodies in the API layer.
|
Revision tags: llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1 |
|
#
80814287 |
| 24-Jan-2020 |
Raphael Isemann <teemperor@gmail.com> |
[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 |
|
#
27a14f19 |
| 03-Oct-2019 |
Jim Ingham <jingham@apple.com> |
Pass an SBStructuredData to scripted ThreadPlans on use.
This will allow us to write reusable scripted ThreadPlans, since you can use key/value pairs with known keys in the plan to parametrize its b
Pass an SBStructuredData to scripted ThreadPlans on use.
This will allow us to write reusable scripted ThreadPlans, since you can use key/value pairs with known keys in the plan to parametrize its behavior.
Differential Revision: https://reviews.llvm.org/D68366
llvm-svn: 373675
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 |
|
#
248a1305 |
| 23-May-2019 |
Konrad Kleine <kkleine@redhat.com> |
[lldb] NFC modernize codebase with modernize-use-nullptr
Summary: NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codeba
[lldb] NFC modernize codebase with modernize-use-nullptr
Summary: NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using `nullptr` instread of `0` or `NULL`. See https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html for more information.
This is the command I ran and I to fix and format the code base:
``` run-clang-tidy.py \ -header-filter='.*' \ -checks='-*,modernize-use-nullptr' \ -fix ~/dev/llvm-project/lldb/.* \ -format \ -style LLVM \ -p ~/llvm-builds/debug-ninja-gcc ```
NOTE: There were also changes to `llvm/utils/unittest` but I did not include them because I felt that maybe this library shall be updated in isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
show more ...
|
Revision tags: llvmorg-8.0.1-rc1 |
|
#
8b3af63b |
| 10-Apr-2019 |
Jonas Devlieghere <jonas@devlieghere.com> |
[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 ...
|
#
26ca5a57 |
| 09-Apr-2019 |
Pavel Labath <pavel@labath.sk> |
Remove unneeded #ifdef SWIGs
Summary: Some of these were present in files which should never be read by swig (and we also had one in the interface file, which is only read by swig). They are probabl
Remove unneeded #ifdef SWIGs
Summary: Some of these were present in files which should never be read by swig (and we also had one in the interface file, which is only read by swig). They are probably leftovers from the time when we were running swig over lldb headers directly.
While writing this patch, I noticed that some of the #ifdefs were guarding public functions that were operating on lldb_private data types. While it wasn't strictly necessary for this patch, I made these private, as nobody should really be accessing them. This can potentially break existing code if it happened to use these methods, though it will only break at build time -- if someone builds against an old header, he should still be able to link to a new lldb library, since the functions are still there.
We could keep these public for backward compatbility, but I would argue that if anyone was actually using these functions for anything, his code is already broken.
Reviewers: JDevlieghere, clayborg, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60400
llvm-svn: 357984
show more ...
|
#
306809f2 |
| 03-Apr-2019 |
Jonas Devlieghere <jonas@devlieghere.com> |
[Reproducers] Capture return values of functions returning by ptr/ref
For some reason I had convinced myself that functions returning by pointer or reference do not require recording their result. H
[Reproducers] Capture return values of functions returning by ptr/ref
For some reason I had convinced myself that functions returning by pointer or reference do not require recording their result. However, after further considering I don't see how that could work, at least not with the current implementation. Interestingly enough, the reproducer instrumentation already (mostly) accounts for this, though the lldb-instr tool did not.
This patch adds the missing macros and updates the lldb-instr tool.
Differential revision: https://reviews.llvm.org/D60178
llvm-svn: 357639
show more ...
|
#
ae211ece |
| 19-Mar-2019 |
Michal Gorny <mgorny@gentoo.org> |
[lldb] [Reproducer] Move SBRegistry registration into declaring files
Move SBRegistry method registrations from SBReproducer.cpp into files declaring the individual APIs, in order to reduce the memo
[lldb] [Reproducer] Move SBRegistry registration into declaring files
Move SBRegistry method registrations from SBReproducer.cpp into files declaring the individual APIs, in order to reduce the memory consumption during build and improve maintainability. The current humongous SBRegistry constructor exhausts all memory on a NetBSD system with 4G RAM + 4G swap, therefore making it impossible to build LLDB.
Differential Revision: https://reviews.llvm.org/D59427
llvm-svn: 356481
show more ...
|
Revision tags: llvmorg-8.0.0, llvmorg-8.0.0-rc5 |
|
#
7f5237bc |
| 11-Mar-2019 |
Pavel Labath <pavel@labath.sk> |
Add "operator bool" to SB APIs
Summary: Our python version of the SB API has (the python equivalent of) operator bool, but the C++ version doesn't.
This is because our python operators are added by
Add "operator bool" to SB APIs
Summary: Our python version of the SB API has (the python equivalent of) operator bool, but the C++ version doesn't.
This is because our python operators are added by modify-python-lldb.py, which performs postprocessing on the swig-generated interface files.
In this patch, I add the "operator bool" to all SB classes which have an IsValid method (which is the same logic used by modify-python-lldb.py). This way, we make the two interfaces more constent, and it allows us to rely on swig's automatic syntesis of python __nonzero__ methods instead of doing manual fixups.
Reviewers: zturner, jingham, clayborg, jfb, serge-sans-paille
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D58792
llvm-svn: 355824
show more ...
|
Revision tags: llvmorg-8.0.0-rc4 |
|
#
baf5664f |
| 06-Mar-2019 |
Jonas Devlieghere <jonas@devlieghere.com> |
[Reproducers] Add SBReproducer macros
This patch adds the SBReproducer macros needed to capture and reply the corresponding calls. This patch was generated by running the lldb-instr tool on the API
[Reproducers] Add SBReproducer macros
This patch adds the SBReproducer macros needed to capture and reply the corresponding calls. This patch was generated by running the lldb-instr tool on the API source files.
Differential revision: https://reviews.llvm.org/D57475
llvm-svn: 355459
show more ...
|
Revision tags: llvmorg-8.0.0-rc3 |
|
#
796ac80b |
| 11-Feb-2019 |
Jonas Devlieghere <jonas@devlieghere.com> |
Use std::make_shared in LLDB (NFC)
Unlike std::make_unique, which is only available since C++14, std::make_shared is available since C++11. Not only is std::make_shared a lot more readable compared
Use std::make_shared in LLDB (NFC)
Unlike std::make_unique, which is only available since C++14, std::make_shared is available since C++11. Not only is std::make_shared a lot more readable compared to ::reset(new), it also performs a single heap allocation for the object and control block.
Differential revision: https://reviews.llvm.org/D57990
llvm-svn: 353764
show more ...
|
Revision tags: 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 <chandlerc@gmail.com> |
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 |
|
#
e103ae92 |
| 15-Nov-2018 |
Jonas Devlieghere <jonas@devlieghere.com> |
Add setting to require hardware breakpoints.
When debugging read-only memory we cannot use software breakpoint. We already have support for hardware breakpoints and users can specify them with `-H`.
Add setting to require hardware breakpoints.
When debugging read-only memory we cannot use software breakpoint. We already have support for hardware breakpoints and users can specify them with `-H`. However, there's no option to force LLDB to use hardware breakpoints internally, for example while stepping.
This patch adds a setting target.require-hardware-breakpoint that forces LLDB to always use hardware breakpoints. Because hardware breakpoints are a limited resource and can fail to resolve, this patch also extends error handling in thread plans, where breakpoints are used for stepping.
Differential revision: https://reviews.llvm.org/D54221
llvm-svn: 346920
show more ...
|
Revision tags: llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1 |
|
#
c1c0fac7 |
| 25-Oct-2018 |
Aleksandr Urakov <aleksandr.urakov@jetbrains.com> |
[API] Extend the `SBThreadPlan` interface
Summary: This patch extends the `SBThreadPlan` to allow retrieving of thread plans for scripted steps.
Reviewers: labath, zturner, jingham
Reviewed By: ji
[API] Extend the `SBThreadPlan` interface
Summary: This patch extends the `SBThreadPlan` to allow retrieving of thread plans for scripted steps.
Reviewers: labath, zturner, jingham
Reviewed By: jingham
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D53361
llvm-svn: 345247
show more ...
|
Revision tags: llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2 |
|
#
d821c997 |
| 07-Aug-2018 |
Pavel Labath <pavel@labath.sk> |
Move RegisterValue,Scalar,State from Core to Utility
These three classes have no external dependencies, but they are used from various low-level APIs. Moving them down to Utility improves overall co
Move RegisterValue,Scalar,State from Core to Utility
These three classes have no external dependencies, but they are used from various low-level APIs. Moving them down to Utility improves overall code layering (although it still does not break any particular dependency completely).
The XCode project will need to be updated after this change.
Differential Revision: https://reviews.llvm.org/D49740
llvm-svn: 339127
show more ...
|
Revision tags: 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 <aprantl@apple.com> |
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 ...
|