|
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 |
|
| #
c34698a8 |
| 03-Feb-2022 |
Pavel Labath <[email protected]> |
[lldb] Rename Logging.h to LLDBLog.h and clean up includes
Most of our code was including Log.h even though that is not where the "lldb" log channel is defined (Log.h defines the generic logging inf
[lldb] Rename Logging.h to LLDBLog.h and clean up includes
Most of our code was including Log.h even though that is not where the "lldb" log channel is defined (Log.h defines the generic logging infrastructure). This worked because Log.h included Logging.h, even though it should.
After the recent refactor, it became impossible the two files include each other in this direction (the opposite inclusion is needed), so this patch removes the workaround that was put in place and cleans up all files to include the right thing. It also renames the file to LLDBLog to better reflect its purpose.
show more ...
|
|
Revision tags: llvmorg-15-init |
|
| #
a007a6d8 |
| 31-Jan-2022 |
Pavel Labath <[email protected]> |
[lldb] Convert "LLDB" log channel to the new API
|
|
Revision tags: llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1 |
|
| #
58492191 |
| 05-Oct-2021 |
Michał Górny <[email protected]> |
[lldb] [ABI] Apply AugmentRegisterInfo() to DynamicRegisterInfo::Registers
Call ABI::AugmentRegisterInfo() once with a vector of all defined registers rather than calling it for every individual reg
[lldb] [ABI] Apply AugmentRegisterInfo() to DynamicRegisterInfo::Registers
Call ABI::AugmentRegisterInfo() once with a vector of all defined registers rather than calling it for every individual register. Move and rename RemoteRegisterInfo from gdb-remote to DynamicRegisterInfo::Register, and use this class when augmenting registers.
Differential Revision: https://reviews.llvm.org/D111142
show more ...
|
| #
89b57061 |
| 08-Oct-2021 |
Reid Kleckner <[email protected]> |
Move TargetRegistry.(h|cpp) from Support to MC
This moves the registry higher in the LLVM library dependency stack. Every client of the target registry needs to link against MC anyway to actually us
Move TargetRegistry.(h|cpp) from Support to MC
This moves the registry higher in the LLVM library dependency stack. Every client of the target registry needs to link against MC anyway to actually use the target, so we might as well move this out of Support.
This allows us to ensure that Support doesn't have includes from MC/*.
Differential Revision: https://reviews.llvm.org/D111454
show more ...
|
|
Revision tags: 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 |
|
| #
057efa99 |
| 11-Feb-2021 |
Adrian Prantl <[email protected]> |
Make the error condition in Value::ValueType explicit (NFC)
The comment for ValueType claims that all values <1 are errors, but not all switch statements take this into account. This patch introduce
Make the error condition in Value::ValueType explicit (NFC)
The comment for ValueType claims that all values <1 are errors, but not all switch statements take this into account. This patch introduces an explicit Error case and deletes all default: cases, so we get warned about incomplete switch coverage.
https://reviews.llvm.org/D96537
show more ...
|
|
Revision tags: 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 |
|
| #
5d645743 |
| 03-Nov-2020 |
Pavel Labath <[email protected]> |
[lldb] Delete Value::Vector class
This class and it's surroundings contain a lot of shady code, but as far as I can tell all of that code is unreachable (there is no code actually setting the value
[lldb] Delete Value::Vector class
This class and it's surroundings contain a lot of shady code, but as far as I can tell all of that code is unreachable (there is no code actually setting the value to eValueTypeVector).
According to history this class was introduced in 2012 in r167033/0665a0f09. At that time, the code seemed to serve some purpose, and it had two entry points (in Value::SetContext and ClangExpressionDeclMap::LookupDecl). The first entry point was deleted in D17897 and the second one in r179842/44342735.
The stated purpose of the patch introducing this class was to fix TestRegisters.py, and "expr $xmm0" in particular. Both of these things function perfectly well these days without this class.
show more ...
|
| #
24e07570 |
| 13-Oct-2020 |
Raphael Isemann <[email protected]> |
[lldb] Remove all the RegisterInfo name constification code
RegisterInfo's `reg_name`/`reg_alt_name` fields are C-Strings and are supposed to only be generated from a ConstString. The reason for tha
[lldb] Remove all the RegisterInfo name constification code
RegisterInfo's `reg_name`/`reg_alt_name` fields are C-Strings and are supposed to only be generated from a ConstString. The reason for that is that `DynamicRegisterInfo::GetRegisterInfo` and `RegInfoBasedABI::GetRegisterInfoByName` try to optimise finding registers by name by only comparing the C string pointer values instead of the underlying strings. This only works if both C strings involved in the comparison come from a ConstString. If one of the two C strings doesn't come from a ConstString the comparison won't work (and most likely will silently fail).
I added an assert in b0060c3a7868ef026d95d0cf8a076791ef74f474 which checks that both strings come from a ConstString. Apparently not all ABI plugins are generating their register names via ConstString, so this code is now not just silently failing but also asserting.
In D88375 we did a shady fix for the MIPS plugins by just copying the ConstString setup code to that plugin, but we still need to fix ABISysV_arc, ABISysV_ppc and ABISysV_ppc64 plugins.
I would say we just fix the remaining plugins by removing the whole requirement to have the register names coming from ConstStrings. I really doubt that we actually save any time with the whole ConstString search trick (searching ~50 strings that have <4 characters doesn't sound more expensive than calling the really expensive ConstString constructor + comparing the same amount of pointer values). Also whatever small percentage of LLDB's runtime is actually spend in this function is anyway not worth the complexity of this approach.
This patch just removes all this and just does a normal string comparison.
Reviewed By: JDevlieghere, labath
Differential Revision: https://reviews.llvm.org/D88490
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 |
|
| #
67d67ebe |
| 20-Mar-2020 |
Jim Ingham <[email protected]> |
Internal expressions shouldn't increment the result variable numbering.
There an option: EvaluateExpressionOptions::SetResultIsInternal to indicate whether the result number should be returned to th
Internal expressions shouldn't increment the result variable numbering.
There an option: EvaluateExpressionOptions::SetResultIsInternal to indicate whether the result number should be returned to the pool or not. It got broken when the PersistentExpressionState was refactored.
This fixes the issue and provides a test of the behavior.
Differential Revision: https://reviews.llvm.org/D76532
show more ...
|
|
Revision tags: llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3 |
|
| #
b0060c3a |
| 19-Feb-2020 |
Raphael Isemann <[email protected]> |
[lldb] Make comparing RegisterInfo::[alt_]name's pointer value less footy-shooty
Comparing those two `const char *` values relies on the assumption that both strings were created by a ConstString. L
[lldb] Make comparing RegisterInfo::[alt_]name's pointer value less footy-shooty
Comparing those two `const char *` values relies on the assumption that both strings were created by a ConstString. Let's check that assumption with an assert as otherwise this code silently does nothing and that's not great.
show more ...
|
| #
8f95a82b |
| 17-Feb-2020 |
Jonas Devlieghere <[email protected]> |
[lldb] Fix Windows bot.
Should fix error C2039: 'toupper': is not a member of 'std'.
|
| #
b2d64b69 |
| 17-Feb-2020 |
Pavel Labath <[email protected]> |
[lldb] Fix build error from 07355c1c08b
The error is: no matching function for call to 'transform(std::string&, std::__cxx11::basic_string<char>::iterator, <unresolved overloaded function type>)'
T
[lldb] Fix build error from 07355c1c08b
The error is: no matching function for call to 'transform(std::string&, std::__cxx11::basic_string<char>::iterator, <unresolved overloaded function type>)'
The fix: replace llvm::transform with an equally simple hand-rolled loop.
show more ...
|
|
Revision tags: llvmorg-10.0.0-rc2 |
|
| #
07355c1c |
| 03-Feb-2020 |
Pavel Labath <[email protected]> |
[lldb] Delete register info definitions in the x86_64 ABI classes
Summary: These definitions are used to "augment" information received from the remote target with eh/debug frame and "generic" regis
[lldb] Delete register info definitions in the x86_64 ABI classes
Summary: These definitions are used to "augment" information received from the remote target with eh/debug frame and "generic" register numbers.
Besides being verbose, this information was also incomplete (new registers like xmm16-31 were missing) and sometimes even downright wrong (ymm register numbers).
Most of this information is available via llvm's MCRegisterInfo. This patch creates a new class, MCBasedABI, which retrieves the eh and debug frame register numbers this way. The tricky part here is that the llvm class uses all-caps register names, whereas lldb register are lowercase, and sometimes called slightly differently. Therefore this class introduces some hooks to allow a subclass to customize the MC lookup. The subclass also needs to suply the "generic" register numbers, as this is an lldb invention.
This patch ports the x86_64 ABI classes to use the new register info mechanism. It also creates a new "ABIx86_64" class which can be used to house code common to x86_64 both ABIs. Right now, this just consists of a single function, but there are plenty of other things that could be moved here too.
Reviewers: JDevlieghere, jasonmolenda
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74244
show more ...
|
| #
12e32d32 |
| 02-Feb-2020 |
Pavel Labath <[email protected]> |
[lldb] Introduce "RegInfoBasedABI"
Summary: This patch creates a new subclass of the ABI class in order to abstract away the mechanism in which we "augment" register information. This enables altern
[lldb] Introduce "RegInfoBasedABI"
Summary: This patch creates a new subclass of the ABI class in order to abstract away the mechanism in which we "augment" register information. This enables alternate augmentation strategies to be introduced.
All existing ABI classes have been modified to inherit from RegInfoBasedABI, but they will be refactored in subsequent patches.
Reviewers: JDevlieghere, jasonmolenda
Subscribers: sdardis, nemanjai, kbarton, jrtc27, atanasyan, jsji, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74243
show more ...
|
|
Revision tags: llvmorg-10.0.0-rc1 |
|
| #
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 |
|
| #
e9331a56 |
| 08-Jan-2020 |
Adrian Prantl <[email protected]> |
Add missing nullptr checks.
GetPersistentExpressionStateForLanguage() can return a nullptr if it cannot construct a typesystem. This patch adds missing nullptr checks at all uses.
Inspired by rdar:
Add missing nullptr checks.
GetPersistentExpressionStateForLanguage() can return a nullptr if it cannot construct a typesystem. This patch adds missing nullptr checks at all uses.
Inspired by rdar://problem/58317195
Differential Revision: https://reviews.llvm.org/D72413
show more ...
|
|
Revision tags: llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2 |
|
| #
2b8db387 |
| 03-Dec-2019 |
Pavel Labath <[email protected]> |
[lldb] Move register info "augmentation" from gdb-remote into ABI
Summary: Previously the ABI plugin exposed some "register infos" and the gdb-remote code used those to fill in the missing bits. Now
[lldb] Move register info "augmentation" from gdb-remote into ABI
Summary: Previously the ABI plugin exposed some "register infos" and the gdb-remote code used those to fill in the missing bits. Now, the "filling in" code is in the ABI plugin itself, and the gdb-remote code just invokes that.
The motivation for this is two-fold: a) the "augmentation" logic is useful outside of process gdb-remote. For instance, it would allow us to avoid repeating the register number definitions in minidump code. b) It gives more implementation freedom to the ABI classes. Now that these "register infos" are essentially implementation details, classes can use other methods to obtain dwarf/eh_frame register numbers -- for instance they can consult llvm MC layer.
Since the augmentation code was not currently tested anywhere, I took the opportunity to create a simple test for it.
Reviewers: jasonmolenda, clayborg, tatyana-krasnukha
Subscribers: aprantl, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70906
show more ...
|
|
Revision tags: llvmorg-9.0.1-rc1 |
|
| #
d0b44dbe |
| 25-Sep-2019 |
Pavel Labath <[email protected]> |
Have ABI plugins vend llvm MCRegisterInfo data
Summary: I was recently surprised to learn that there is a total of 2 (two) users of the register info definitions contained in the ABI plugins. Yet, t
Have ABI plugins vend llvm MCRegisterInfo data
Summary: I was recently surprised to learn that there is a total of 2 (two) users of the register info definitions contained in the ABI plugins. Yet, the defitions themselves span nearly 10kLOC. The two users are: - dwarf expression pretty printer - the mechanism for augmenting the register info definitions obtained over gdb-remote protocol (AugmentRegisterInfoViaABI)
Both of these uses need the DWARF an EH register numbers, which is information that is already available in LLVM. This patch makes it possible to do so.
It adds a GetMCRegisterInfo method to the ABI class, which every class is expected to implement. Normally, it should be sufficient to obtain the definitions from the appropriate llvm::Target object (for which I provide a utility function), but the subclasses are free to construct it in any way they deem fit.
We should be able to always get the MCRegisterInfo object from llvm, with one important exception: if the relevant llvm target was disabled at compile time. To handle this, I add a mechanism to disable the compilation of ABI plugins based on the value of LLVM_TARGETS_TO_BUILD cmake setting. This ensures all our existing are able to create their MCRegisterInfo objects.
The new MCRegisterInfo api is not used yet, but the intention is to make use of it in follow-up patches.
Reviewers: jasonmolenda, aprantl, JDevlieghere, tatyana-krasnukha
Subscribers: wuzish, nemanjai, mgorny, kbarton, atanasyan, lldb-commits
Differential Revision: https://reviews.llvm.org/D67965
llvm-svn: 372862
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 |
|
| #
e574f8b3 |
| 17-Jul-2019 |
Alex Langford <[email protected]> |
[Target][NFCI] Rename variable
This variable doesn't have anything to do with clang.
llvm-svn: 366292
|
|
Revision tags: llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2 |
|
| #
4dc0acc9 |
| 31-May-2019 |
Alex Langford <[email protected]> |
[Target] Remove ABI's dependence on ExpressionParser
llvm-svn: 362259
|
|
Revision tags: llvmorg-8.0.1-rc1, 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, llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2 |
|
| #
03219f7f |
| 30-Apr-2018 |
Adrian Prantl <[email protected]> |
Refactor GetNextPersistentVariableName into a non-virtual method that takes a prefix string. This simplifies the implementation and allows plugins such as the Swift plugin to supply different prefixe
Refactor GetNextPersistentVariableName into a non-virtual method that takes a prefix string. This simplifies the implementation and allows plugins such as the Swift plugin to supply different prefixes for return and error variables.
rdar://problem/39299889
Differential Revision: https://reviews.llvm.org/D46088
llvm-svn: 331235
show more ...
|
| #
5435f780 |
| 30-Apr-2018 |
Adrian Prantl <[email protected]> |
Move the persistent variable counter into Target so it can be shared across multiple language plugins.
In a multi-language project it is counterintuitive to have a result variables reuse numbers jus
Move the persistent variable counter into Target so it can be shared across multiple language plugins.
In a multi-language project it is counterintuitive to have a result variables reuse numbers just because they are using a different language plugin in LLDB (but not for example, when they are Objective-C versus C++, since they are both handled by Clang).
This is NFC on llvm.org except for the Go plugin.
rdar://problem/39299889
Differential Revision: https://reviews.llvm.org/D46083
llvm-svn: 331234
show more ...
|
| #
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 ...
|