|
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 |
|
| #
99515783 |
| 24-Mar-2022 |
Jason Molenda <[email protected]> |
Don't search for sim SDK path until we know we need it
When iterating over all Platforms looking for the best one, on a Mac the Simulator platforms (iOS, tvOS, watchOS) will first find their SDK dir
Don't search for sim SDK path until we know we need it
When iterating over all Platforms looking for the best one, on a Mac the Simulator platforms (iOS, tvOS, watchOS) will first find their SDK directory by calling xcrun, then decide if they should activate or not. When that SDK is absent, the call to xcrun to find it can be very slow. This patch delays that directory search until we know we're activating this platform, so non-simulator environments don't pay a perf cost ever time they go through the list of platforms.
Differential Revision: https://reviews.llvm.org/D122373 rdar://87960090
show more ...
|
| #
dde487e5 |
| 14-Mar-2022 |
Jonas Devlieghere <[email protected]> |
[lldb] Plumb process host architecture through platform selection
To allow us to select a different platform based on where the process is running, plumb the process host architecture through platfo
[lldb] Plumb process host architecture through platform selection
To allow us to select a different platform based on where the process is running, plumb the process host architecture through platform selection.
This patch is in preparation for D121444 which needs this functionality to tell apart iOS binaries running on Apple Silicon vs on a remote iOS device.
Differential revision: https://reviews.llvm.org/D121484
show more ...
|
|
Revision tags: 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 |
|
| #
e7c48f3c |
| 17-Dec-2021 |
Pavel Labath <[email protected]> |
[lldb] Use GetSupportedArchitectures on darwin platforms
This finishes the GetSupportedArchitectureAtIndex migration. There are opportunities to simplify this even further, but I am going to leave t
[lldb] Use GetSupportedArchitectures on darwin platforms
This finishes the GetSupportedArchitectureAtIndex migration. There are opportunities to simplify this even further, but I am going to leave that to the platform owners.
Differential Revision: https://reviews.llvm.org/D116028
show more ...
|
|
Revision tags: llvmorg-13.0.1-rc1 |
|
| #
93c7ed8c |
| 26-Oct-2021 |
Pavel Labath <[email protected]> |
[lldb] Fix PlatformAppleSimulator for a458ef4f
|
| #
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 |
|
| #
bd590a5f |
| 16-Sep-2021 |
Pavel Labath <[email protected]> |
[lldb] Make Platform::DebugProcess take a Target reference
instead of a pointer. There are just two callers of this function, and both of them have a valid target pointer, so there's no need for all
[lldb] Make Platform::DebugProcess take a Target reference
instead of a pointer. There are just two callers of this function, and both of them have a valid target pointer, so there's no need for all implementations to concern themselves with whether the pointer is null.
show more ...
|
|
Revision tags: llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init |
|
| #
fd2433e1 |
| 02-Jul-2021 |
Jonas Devlieghere <[email protected]> |
[lldb] Replace default bodies of special member functions with = default;
Replace default bodies of special member functions with = default;
$ run-clang-tidy.py -header-filter='lldb' -checks='-*,mo
[lldb] Replace default bodies of special member functions with = default;
Replace default bodies of special member functions with = default;
$ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-equals-default' -fix ,
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-equals-default.html
Differential revision: https://reviews.llvm.org/D104041
show more ...
|
|
Revision tags: 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 |
|
| #
ac29c352 |
| 09-Mar-2021 |
Vedant Kumar <[email protected]> |
[lldb/Platform] Skip very slow xcrun queries for simulator platforms, NFC
GetXcodeSDK() consistently takes over 1 second to complete if the queried SDK is missing, because `xcrun` doesn't cache nega
[lldb/Platform] Skip very slow xcrun queries for simulator platforms, NFC
GetXcodeSDK() consistently takes over 1 second to complete if the queried SDK is missing, because `xcrun` doesn't cache negative lookups.
Because there are multiple simulator platforms, this can add 4+ seconds to `lldb -b some_object_file.o`.
To work around this, skip the call to GetXcodeSDK() when setting up simulator platforms if the specified arch doesn't have what looks like a simulator triple.
Some other ways to fix this: - Fix caching in xcrun (rdar://74882205) - Test for arch compat before calling SomePlatform::CreateInstance() (much larger change)
Differential Revision: https://reviews.llvm.org/D98272
show more ...
|
|
Revision tags: 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 |
|
| #
61bfc703 |
| 30-Oct-2020 |
Joseph Tremoulet <[email protected]> |
[lldb] GetSharedModule: Collect old modules in SmallVector
The various GetSharedModule methods have an optional out parameter for the old module when a file has changed or been replaced, which the T
[lldb] GetSharedModule: Collect old modules in SmallVector
The various GetSharedModule methods have an optional out parameter for the old module when a file has changed or been replaced, which the Target uses to keep its module list current/correct. We've been using a single ModuleSP to track "the" old module, and this change switches to using a SmallVector of ModuleSP, which has a couple benefits: - There are multiple codepaths which may discover an old module, and this centralizes the code for how to handle multiples in one place, in the Target code. With the single ModuleSP, each place that may discover an old module is responsible for how it handles multiples, and the current code is inconsistent (some code paths drop the first old module, others drop the second). - The API will be more natural for identifying old modules in routines that work on sets, like ModuleList::ReplaceEquivalent (which I plan on updating to report old module(s) in a subsequent change to fix a bug).
I'm not convinced we can ever actually run into the case that multiple old modules are found in the same GetOrCreateModule call, but I think this change makes sense regardless, in light of the above.
When an old module is reported, Target::GetOrCreateModule calls m_images.ReplaceModule, which doesn't allow multiple "old" modules; the new code calls ReplaceModule for the first "old" module, and for any subsequent old modules it logs the event and calls m_images.Remove.
Reviewed By: jingham
Differential Revision: https://reviews.llvm.org/D89156
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 |
|
| #
38b419eb |
| 07-Aug-2020 |
Adrian Prantl <[email protected]> |
Factor out reference-counting code from PlatformApple*
into PlatformAppleSimulator. This is legal because that is the only entry point for the Terminate/Initialize functions.
|
| #
243903f3 |
| 05-Aug-2020 |
Adrian Prantl <[email protected]> |
Factor out common code from the iPhone/AppleTV/WatchOS simulator platform plugins. (NFC)
The implementation of these classes was copied & pasted from the iPhone simulator plugin with only a handful
Factor out common code from the iPhone/AppleTV/WatchOS simulator platform plugins. (NFC)
The implementation of these classes was copied & pasted from the iPhone simulator plugin with only a handful of configuration parameters substituted. This patch moves the redundant implementations into the base class PlatformAppleSimulator.
Differential Revision: https://reviews.llvm.org/D85243
show more ...
|
|
Revision tags: llvmorg-11.0.0-rc1 |
|
| #
4c6eebf8 |
| 24-Jul-2020 |
Fred Riss <[email protected]> |
[lldb/AppleSimulator] Always provide a -simulator environment
Summary: This commit is somewhat NFC-ish today as the environment of triples is not considered when comparing s if one of them is not se
[lldb/AppleSimulator] Always provide a -simulator environment
Summary: This commit is somewhat NFC-ish today as the environment of triples is not considered when comparing s if one of them is not set (I plan to change that).
We have made simulator triples unambiguous these days, but the simulator platforms still advertise triples without the environment. This wasn't an issue when the sims ran only on a very different architecure than the real device, but this has changed with Apple Silicon.
This patch simplifies the way GetSupportedArchitectureAtIndex is implemented for the sim platforms and adds the environment. It also trivially adds support for Apple Silicon to those platforms.
Reviewers: aprantl
Subscribers: lldb-commits
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 |
|
| #
7e825abd |
| 16-Jun-2020 |
Adrian Prantl <[email protected]> |
Repair support for launching ios/tv/watch simulator binaries through platform
and delete a bunch (but not all) redundant code. If you compare the remaining implementations of Platform*Simulator.cpp,
Repair support for launching ios/tv/watch simulator binaries through platform
and delete a bunch (but not all) redundant code. If you compare the remaining implementations of Platform*Simulator.cpp, there is still an obvious leftover cleanup task.
Specifically, this patch
- removes SDK initialization from dotest (there is equivalent but more complete code in Makefile.rules)
- make Platform*Simulator inherit the generic implementation of PlatformAppleSimulator (more can be done here)
- simplify the platform logic in Makefile.rules
- replace the custom SDK finding logic in Platform*Simulator with XcodeSDK
- adds a test for each supported simulator
Differential Revision: https://reviews.llvm.org/D81980
show more ...
|
| #
64ec505d |
| 15-Jun-2020 |
Jonas Devlieghere <[email protected]> |
[lldb] Rename Master/Slave to Primary/Secondary (NFC)
|
| #
dc0f0980 |
| 10-Jun-2020 |
Raphael Isemann <[email protected]> |
[lldb] Fix a crash in PlatformAppleSimulator::GetCoreSimulatorPath when Xcode developer directory can't be found
Summary:
`PlatformAppleSimulator::GetCoreSimulatorPath` currently checks if `m_core_
[lldb] Fix a crash in PlatformAppleSimulator::GetCoreSimulatorPath when Xcode developer directory can't be found
Summary:
`PlatformAppleSimulator::GetCoreSimulatorPath` currently checks if `m_core_simulator_framework_path` wasn't set yet and then tries to calculate its actual value. However, if `GetXcodeDeveloperDirectory` returns an invalid FileSpec, `m_core_simulator_framework_path` is never assigned a value which causes that the `return m_core_simulator_framework_path.getValue();` at the end of the function will trigger an assert.
This patch just assigns an invalid FileSpec to `m_core_simulator_framework_path` which seems what the calling code in `PlatformAppleSimulator::LoadCoreSimulator` expects as an error value.
I assume this can be reproduces on machines that don't have an Xcode installation, but this patch is mostly based on this backtrace I received from someone else that tried to run the test suite:
``` Assertion failed: (hasVal), function getValue, file llvm/include/llvm/ADT/Optional.h, line 73. [...] 3 libsystem_c.dylib 0x00007fff682a1ac6 __assert_rtn + 314 4 liblldb.11.0.0git.dylib 0x000000010b835931 PlatformAppleSimulator::GetCoreSimulatorPath() (.cold.1) + 33 5 liblldb.11.0.0git.dylib 0x0000000107e92f11 PlatformAppleSimulator::GetCoreSimulatorPath() + 369 6 liblldb.11.0.0git.dylib 0x0000000107e9383e void std::__1::__call_once_proxy<std::__1::tuple<PlatformAppleSimulator::LoadCoreSimulator()::$_1&&> >(void*) + 30 7 libc++.1.dylib 0x00007fff654d5bea std::__1::__call_once(unsigned long volatile&, void*, void (*)(void*)) + 139 8 liblldb.11.0.0git.dylib 0x0000000107e92019 PlatformAppleSimulator::LaunchProcess(lldb_private::ProcessLaunchInfo&) + 89 9 liblldb.11.0.0git.dylib 0x0000000107e92be5 PlatformAppleSimulator::DebugProcess(lldb_private::ProcessLaunchInfo&, lldb_private::Debugger&, lldb_private::Target*, lldb_private::Status&) + 101 10 liblldb.11.0.0git.dylib 0x0000000107cb044d lldb_private::Target::Launch(lldb_private::ProcessLaunchInfo&, lldb_private::Stream*) + 669 11 liblldb.11.0.0git.dylib 0x000000010792c9c5 lldb::SBTarget::Launch(lldb::SBLaunchInfo&, lldb::SBError&) + 1109 12 liblldb.11.0.0git.dylib 0x0000000107a92acd _wrap_SBTarget_Launch(_object*, _object*) + 477 13 org.python.python 0x000000010681076f PyCFunction_Call + 321 14 org.python.python 0x000000010689ee12 _PyEval_EvalFrameDefault + 7738 ```
Reviewers: JDevlieghere, jasonmolenda
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D80997
show more ...
|
| #
3d7b926d |
| 05-Jun-2020 |
Adrian Prantl <[email protected]> |
Move GetXcode*Directory into HostInfo (NFC)
These functions really don't belong into PlatformDarwin, since they actualy query state of the Host and not of the remote platform.
|
|
Revision tags: llvmorg-10.0.1-rc1 |
|
| #
457eb05d |
| 27-Mar-2020 |
Jonas Devlieghere <[email protected]> |
[lldb/PlatformMacOSX] Re-implement GetDeveloperDirectory
GetDeveloperDirectory returns a const char* which is NULL when we cannot find the developer directory. This crashes in PlatformDarwinKernel::
[lldb/PlatformMacOSX] Re-implement GetDeveloperDirectory
GetDeveloperDirectory returns a const char* which is NULL when we cannot find the developer directory. This crashes in PlatformDarwinKernel::CollectKextAndKernelDirectories because we're unconditionally assigning it to a std::string. Coincidentally I just refactored a bunch of code in PlatformMacOSX so instead of a ad-hoc fix I've reimplemented the method based on GetXcodeContentsDirectory.
The change is mostly NFC. Obviously it fixes the crash, but it also removes support for finding the Xcode directory through he legacy $XCODE_SELECT_PREFIX_DIR/usr/share/xcode-select/xcode_dir_path.
Differential revision: https://reviews.llvm.org/D76938
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 |
|
| #
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, 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, 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 |
|
| #
8f3be7a3 |
| 01-Nov-2018 |
Jonas Devlieghere <[email protected]> |
[FileSystem] Move path resolution logic out of FileSpec
This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead.
Differential
[FileSystem] Move path resolution logic out of FileSpec
This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead.
Differential revision: https://reviews.llvm.org/D53915
llvm-svn: 345890
show more ...
|
|
Revision tags: 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 ...
|