[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 15:23:27 +08:00
|
|
|
//===-- IOHandler.cpp -----------------------------------------------------===//
|
2014-01-28 07:43:24 +08:00
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2014-01-28 07:43:24 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2017-04-07 05:28:29 +08:00
|
|
|
#include "lldb/Core/IOHandler.h"
|
|
|
|
|
2015-10-28 23:24:19 +08:00
|
|
|
#if defined(__APPLE__)
|
|
|
|
#include <deque>
|
|
|
|
#endif
|
2014-01-28 07:43:24 +08:00
|
|
|
#include <string>
|
|
|
|
|
|
|
|
#include "lldb/Core/Debugger.h"
|
|
|
|
#include "lldb/Core/StreamFile.h"
|
2019-12-13 01:54:48 +08:00
|
|
|
#include "lldb/Host/Config.h"
|
2018-11-12 07:16:43 +08:00
|
|
|
#include "lldb/Host/File.h"
|
|
|
|
#include "lldb/Utility/Predicate.h"
|
2020-08-22 15:36:32 +08:00
|
|
|
#include "lldb/Utility/ReproducerProvider.h"
|
2018-11-12 07:16:43 +08:00
|
|
|
#include "lldb/Utility/Status.h"
|
|
|
|
#include "lldb/Utility/StreamString.h"
|
|
|
|
#include "lldb/Utility/StringList.h"
|
|
|
|
#include "lldb/lldb-forward.h"
|
2017-04-07 05:28:29 +08:00
|
|
|
|
2019-12-13 01:22:34 +08:00
|
|
|
#if LLDB_ENABLE_LIBEDIT
|
2014-01-28 07:43:24 +08:00
|
|
|
#include "lldb/Host/Editline.h"
|
2014-09-28 00:54:22 +08:00
|
|
|
#endif
|
2014-01-28 07:43:24 +08:00
|
|
|
#include "lldb/Interpreter/CommandCompletions.h"
|
|
|
|
#include "lldb/Interpreter/CommandInterpreter.h"
|
2018-11-12 07:16:43 +08:00
|
|
|
#include "llvm/ADT/StringRef.h"
|
2017-04-07 05:28:29 +08:00
|
|
|
|
2019-09-22 09:21:34 +08:00
|
|
|
#ifdef _WIN32
|
2017-06-24 07:55:32 +08:00
|
|
|
#include "lldb/Host/windows/windows.h"
|
2016-03-25 04:35:03 +08:00
|
|
|
#endif
|
|
|
|
|
2018-11-12 07:16:43 +08:00
|
|
|
#include <memory>
|
|
|
|
#include <mutex>
|
2017-04-07 05:28:29 +08:00
|
|
|
|
2018-11-12 07:16:43 +08:00
|
|
|
#include <assert.h>
|
|
|
|
#include <ctype.h>
|
|
|
|
#include <errno.h>
|
|
|
|
#include <locale.h>
|
|
|
|
#include <stdint.h>
|
|
|
|
#include <stdio.h>
|
|
|
|
#include <string.h>
|
|
|
|
#include <type_traits>
|
2017-04-07 05:28:29 +08:00
|
|
|
|
2014-01-28 07:43:24 +08:00
|
|
|
using namespace lldb;
|
|
|
|
using namespace lldb_private;
|
IOHandler: fall back on File::Read if a FILE* isn't available.
Summary:
IOHandler needs to read lines of input from a lldb::File.
The way it currently does this using, FILE*, which is something
we want to avoid now. I'd prefer to just replace the FILE* code
with calls to File::Read, but it contains an awkward and
delicate workaround specific to ctrl-C handling on windows, and
it's not clear if or how that workaround would translate to
lldb::File.
So in this patch, we use use the FILE* if it's available, and only
fall back on File::Read if that's the only option.
I think this is a reasonable approach here for two reasons. First
is that interactive terminal support is the one area where FILE*
can't be avoided. We need them for libedit and curses anyway,
and using them here as well is consistent with that pattern.
The second reason is that the comments express a hope that the
underlying windows bug that's being worked around will be fixed one
day, so hopefully when that happens, that whole path can be deleted.
Reviewers: JDevlieghere, jasonmolenda, labath, lanza
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68622
llvm-svn: 374576
2019-10-12 01:43:32 +08:00
|
|
|
using llvm::None;
|
|
|
|
using llvm::Optional;
|
|
|
|
using llvm::StringRef;
|
|
|
|
|
2014-11-18 03:06:59 +08:00
|
|
|
IOHandler::IOHandler(Debugger &debugger, IOHandler::Type type)
|
2014-01-28 07:43:24 +08:00
|
|
|
: IOHandler(debugger, type,
|
remove File::SetStream(), make new files instead.
Summary:
This patch removes File::SetStream() and File::SetDescriptor(),
and replaces most direct uses of File with pointers to File.
Instead of calling SetStream() on a file, we make a new file and
replace it.
My ultimate goal here is to introduce a new API class SBFile, which
has full support for python io.IOStream file objects. These can
redirect read() and write() to python code, so lldb::Files will
need a way to dispatch those methods. Additionally it will need some
form of sharing and assigning files, as a SBFile will be passed in and
assigned to the main IO streams of the debugger.
In my prototype patch queue, I make File itself copyable and add a
secondary class FileOps to manage the sharing and dispatch. In that
case SBFile was a unique_ptr<File>.
(here: https://github.com/smoofra/llvm-project/tree/files)
However in review, Pavel Labath suggested that it be shared_ptr instead.
(here: https://reviews.llvm.org/D67793)
In order for SBFile to use shared_ptr<File>, everything else should
as well.
If this patch is accepted, I will make SBFile use a shared_ptr
I will remove FileOps from future patches and use subclasses of File
instead.
Reviewers: JDevlieghere, jasonmolenda, zturner, jingham, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67891
llvm-svn: 373090
2019-09-27 22:33:35 +08:00
|
|
|
FileSP(), // Adopt STDIN from top input reader
|
2014-02-06 01:57:57 +08:00
|
|
|
StreamFileSP(), // Adopt STDOUT from top input reader
|
|
|
|
StreamFileSP(), // Adopt STDERR from top input reader
|
2019-03-02 08:20:26 +08:00
|
|
|
0, // Flags
|
|
|
|
nullptr // Shadow file recorder
|
|
|
|
) {}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2014-01-28 07:43:24 +08:00
|
|
|
IOHandler::IOHandler(Debugger &debugger, IOHandler::Type type,
|
remove File::SetStream(), make new files instead.
Summary:
This patch removes File::SetStream() and File::SetDescriptor(),
and replaces most direct uses of File with pointers to File.
Instead of calling SetStream() on a file, we make a new file and
replace it.
My ultimate goal here is to introduce a new API class SBFile, which
has full support for python io.IOStream file objects. These can
redirect read() and write() to python code, so lldb::Files will
need a way to dispatch those methods. Additionally it will need some
form of sharing and assigning files, as a SBFile will be passed in and
assigned to the main IO streams of the debugger.
In my prototype patch queue, I make File itself copyable and add a
secondary class FileOps to manage the sharing and dispatch. In that
case SBFile was a unique_ptr<File>.
(here: https://github.com/smoofra/llvm-project/tree/files)
However in review, Pavel Labath suggested that it be shared_ptr instead.
(here: https://reviews.llvm.org/D67793)
In order for SBFile to use shared_ptr<File>, everything else should
as well.
If this patch is accepted, I will make SBFile use a shared_ptr
I will remove FileOps from future patches and use subclasses of File
instead.
Reviewers: JDevlieghere, jasonmolenda, zturner, jingham, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67891
llvm-svn: 373090
2019-09-27 22:33:35 +08:00
|
|
|
const lldb::FileSP &input_sp,
|
2014-01-28 07:43:24 +08:00
|
|
|
const lldb::StreamFileSP &output_sp,
|
2019-03-02 08:20:26 +08:00
|
|
|
const lldb::StreamFileSP &error_sp, uint32_t flags,
|
|
|
|
repro::DataRecorder *data_recorder)
|
2014-01-28 07:43:24 +08:00
|
|
|
: m_debugger(debugger), m_input_sp(input_sp), m_output_sp(output_sp),
|
2019-03-02 08:20:26 +08:00
|
|
|
m_error_sp(error_sp), m_data_recorder(data_recorder), m_popped(false),
|
|
|
|
m_flags(flags), m_type(type), m_user_data(nullptr), m_done(false),
|
|
|
|
m_active(false) {
|
2014-01-28 07:43:24 +08:00
|
|
|
// If any files are not specified, then adopt them from the top input reader.
|
|
|
|
if (!m_input_sp || !m_output_sp || !m_error_sp)
|
|
|
|
debugger.AdoptTopIOHandlerFilesIfInvalid(m_input_sp, m_output_sp,
|
|
|
|
m_error_sp);
|
|
|
|
}
|
|
|
|
|
2015-10-27 01:00:13 +08:00
|
|
|
IOHandler::~IOHandler() = default;
|
2014-01-28 07:43:24 +08:00
|
|
|
|
|
|
|
int IOHandler::GetInputFD() {
|
remove File::SetStream(), make new files instead.
Summary:
This patch removes File::SetStream() and File::SetDescriptor(),
and replaces most direct uses of File with pointers to File.
Instead of calling SetStream() on a file, we make a new file and
replace it.
My ultimate goal here is to introduce a new API class SBFile, which
has full support for python io.IOStream file objects. These can
redirect read() and write() to python code, so lldb::Files will
need a way to dispatch those methods. Additionally it will need some
form of sharing and assigning files, as a SBFile will be passed in and
assigned to the main IO streams of the debugger.
In my prototype patch queue, I make File itself copyable and add a
secondary class FileOps to manage the sharing and dispatch. In that
case SBFile was a unique_ptr<File>.
(here: https://github.com/smoofra/llvm-project/tree/files)
However in review, Pavel Labath suggested that it be shared_ptr instead.
(here: https://reviews.llvm.org/D67793)
In order for SBFile to use shared_ptr<File>, everything else should
as well.
If this patch is accepted, I will make SBFile use a shared_ptr
I will remove FileOps from future patches and use subclasses of File
instead.
Reviewers: JDevlieghere, jasonmolenda, zturner, jingham, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67891
llvm-svn: 373090
2019-09-27 22:33:35 +08:00
|
|
|
return (m_input_sp ? m_input_sp->GetDescriptor() : -1);
|
2014-01-28 07:43:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
int IOHandler::GetOutputFD() {
|
2016-03-12 04:20:38 +08:00
|
|
|
return (m_output_sp ? m_output_sp->GetFile().GetDescriptor() : -1);
|
2014-01-28 07:43:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
int IOHandler::GetErrorFD() {
|
2016-03-12 04:20:38 +08:00
|
|
|
return (m_error_sp ? m_error_sp->GetFile().GetDescriptor() : -1);
|
2014-01-28 07:43:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
FILE *IOHandler::GetInputFILE() {
|
remove File::SetStream(), make new files instead.
Summary:
This patch removes File::SetStream() and File::SetDescriptor(),
and replaces most direct uses of File with pointers to File.
Instead of calling SetStream() on a file, we make a new file and
replace it.
My ultimate goal here is to introduce a new API class SBFile, which
has full support for python io.IOStream file objects. These can
redirect read() and write() to python code, so lldb::Files will
need a way to dispatch those methods. Additionally it will need some
form of sharing and assigning files, as a SBFile will be passed in and
assigned to the main IO streams of the debugger.
In my prototype patch queue, I make File itself copyable and add a
secondary class FileOps to manage the sharing and dispatch. In that
case SBFile was a unique_ptr<File>.
(here: https://github.com/smoofra/llvm-project/tree/files)
However in review, Pavel Labath suggested that it be shared_ptr instead.
(here: https://reviews.llvm.org/D67793)
In order for SBFile to use shared_ptr<File>, everything else should
as well.
If this patch is accepted, I will make SBFile use a shared_ptr
I will remove FileOps from future patches and use subclasses of File
instead.
Reviewers: JDevlieghere, jasonmolenda, zturner, jingham, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67891
llvm-svn: 373090
2019-09-27 22:33:35 +08:00
|
|
|
return (m_input_sp ? m_input_sp->GetStream() : nullptr);
|
2014-01-28 07:43:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
FILE *IOHandler::GetOutputFILE() {
|
2016-03-12 04:20:38 +08:00
|
|
|
return (m_output_sp ? m_output_sp->GetFile().GetStream() : nullptr);
|
2014-01-28 07:43:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
FILE *IOHandler::GetErrorFILE() {
|
2016-03-12 04:20:38 +08:00
|
|
|
return (m_error_sp ? m_error_sp->GetFile().GetStream() : nullptr);
|
2014-01-28 07:43:24 +08:00
|
|
|
}
|
|
|
|
|
remove File::SetStream(), make new files instead.
Summary:
This patch removes File::SetStream() and File::SetDescriptor(),
and replaces most direct uses of File with pointers to File.
Instead of calling SetStream() on a file, we make a new file and
replace it.
My ultimate goal here is to introduce a new API class SBFile, which
has full support for python io.IOStream file objects. These can
redirect read() and write() to python code, so lldb::Files will
need a way to dispatch those methods. Additionally it will need some
form of sharing and assigning files, as a SBFile will be passed in and
assigned to the main IO streams of the debugger.
In my prototype patch queue, I make File itself copyable and add a
secondary class FileOps to manage the sharing and dispatch. In that
case SBFile was a unique_ptr<File>.
(here: https://github.com/smoofra/llvm-project/tree/files)
However in review, Pavel Labath suggested that it be shared_ptr instead.
(here: https://reviews.llvm.org/D67793)
In order for SBFile to use shared_ptr<File>, everything else should
as well.
If this patch is accepted, I will make SBFile use a shared_ptr
I will remove FileOps from future patches and use subclasses of File
instead.
Reviewers: JDevlieghere, jasonmolenda, zturner, jingham, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67891
llvm-svn: 373090
2019-09-27 22:33:35 +08:00
|
|
|
FileSP &IOHandler::GetInputFileSP() { return m_input_sp; }
|
2014-01-28 07:43:24 +08:00
|
|
|
|
remove File::SetStream(), make new files instead.
Summary:
This patch removes File::SetStream() and File::SetDescriptor(),
and replaces most direct uses of File with pointers to File.
Instead of calling SetStream() on a file, we make a new file and
replace it.
My ultimate goal here is to introduce a new API class SBFile, which
has full support for python io.IOStream file objects. These can
redirect read() and write() to python code, so lldb::Files will
need a way to dispatch those methods. Additionally it will need some
form of sharing and assigning files, as a SBFile will be passed in and
assigned to the main IO streams of the debugger.
In my prototype patch queue, I make File itself copyable and add a
secondary class FileOps to manage the sharing and dispatch. In that
case SBFile was a unique_ptr<File>.
(here: https://github.com/smoofra/llvm-project/tree/files)
However in review, Pavel Labath suggested that it be shared_ptr instead.
(here: https://reviews.llvm.org/D67793)
In order for SBFile to use shared_ptr<File>, everything else should
as well.
If this patch is accepted, I will make SBFile use a shared_ptr
I will remove FileOps from future patches and use subclasses of File
instead.
Reviewers: JDevlieghere, jasonmolenda, zturner, jingham, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67891
llvm-svn: 373090
2019-09-27 22:33:35 +08:00
|
|
|
StreamFileSP &IOHandler::GetOutputStreamFileSP() { return m_output_sp; }
|
2014-01-28 07:43:24 +08:00
|
|
|
|
remove File::SetStream(), make new files instead.
Summary:
This patch removes File::SetStream() and File::SetDescriptor(),
and replaces most direct uses of File with pointers to File.
Instead of calling SetStream() on a file, we make a new file and
replace it.
My ultimate goal here is to introduce a new API class SBFile, which
has full support for python io.IOStream file objects. These can
redirect read() and write() to python code, so lldb::Files will
need a way to dispatch those methods. Additionally it will need some
form of sharing and assigning files, as a SBFile will be passed in and
assigned to the main IO streams of the debugger.
In my prototype patch queue, I make File itself copyable and add a
secondary class FileOps to manage the sharing and dispatch. In that
case SBFile was a unique_ptr<File>.
(here: https://github.com/smoofra/llvm-project/tree/files)
However in review, Pavel Labath suggested that it be shared_ptr instead.
(here: https://reviews.llvm.org/D67793)
In order for SBFile to use shared_ptr<File>, everything else should
as well.
If this patch is accepted, I will make SBFile use a shared_ptr
I will remove FileOps from future patches and use subclasses of File
instead.
Reviewers: JDevlieghere, jasonmolenda, zturner, jingham, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67891
llvm-svn: 373090
2019-09-27 22:33:35 +08:00
|
|
|
StreamFileSP &IOHandler::GetErrorStreamFileSP() { return m_error_sp; }
|
2014-01-28 07:43:24 +08:00
|
|
|
|
2014-02-06 01:57:57 +08:00
|
|
|
bool IOHandler::GetIsInteractive() {
|
remove File::SetStream(), make new files instead.
Summary:
This patch removes File::SetStream() and File::SetDescriptor(),
and replaces most direct uses of File with pointers to File.
Instead of calling SetStream() on a file, we make a new file and
replace it.
My ultimate goal here is to introduce a new API class SBFile, which
has full support for python io.IOStream file objects. These can
redirect read() and write() to python code, so lldb::Files will
need a way to dispatch those methods. Additionally it will need some
form of sharing and assigning files, as a SBFile will be passed in and
assigned to the main IO streams of the debugger.
In my prototype patch queue, I make File itself copyable and add a
secondary class FileOps to manage the sharing and dispatch. In that
case SBFile was a unique_ptr<File>.
(here: https://github.com/smoofra/llvm-project/tree/files)
However in review, Pavel Labath suggested that it be shared_ptr instead.
(here: https://reviews.llvm.org/D67793)
In order for SBFile to use shared_ptr<File>, everything else should
as well.
If this patch is accepted, I will make SBFile use a shared_ptr
I will remove FileOps from future patches and use subclasses of File
instead.
Reviewers: JDevlieghere, jasonmolenda, zturner, jingham, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67891
llvm-svn: 373090
2019-09-27 22:33:35 +08:00
|
|
|
return GetInputFileSP() ? GetInputFileSP()->GetIsInteractive() : false;
|
2014-02-06 01:57:57 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
bool IOHandler::GetIsRealTerminal() {
|
remove File::SetStream(), make new files instead.
Summary:
This patch removes File::SetStream() and File::SetDescriptor(),
and replaces most direct uses of File with pointers to File.
Instead of calling SetStream() on a file, we make a new file and
replace it.
My ultimate goal here is to introduce a new API class SBFile, which
has full support for python io.IOStream file objects. These can
redirect read() and write() to python code, so lldb::Files will
need a way to dispatch those methods. Additionally it will need some
form of sharing and assigning files, as a SBFile will be passed in and
assigned to the main IO streams of the debugger.
In my prototype patch queue, I make File itself copyable and add a
secondary class FileOps to manage the sharing and dispatch. In that
case SBFile was a unique_ptr<File>.
(here: https://github.com/smoofra/llvm-project/tree/files)
However in review, Pavel Labath suggested that it be shared_ptr instead.
(here: https://reviews.llvm.org/D67793)
In order for SBFile to use shared_ptr<File>, everything else should
as well.
If this patch is accepted, I will make SBFile use a shared_ptr
I will remove FileOps from future patches and use subclasses of File
instead.
Reviewers: JDevlieghere, jasonmolenda, zturner, jingham, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67891
llvm-svn: 373090
2019-09-27 22:33:35 +08:00
|
|
|
return GetInputFileSP() ? GetInputFileSP()->GetIsRealTerminal() : false;
|
2014-02-06 01:57:57 +08:00
|
|
|
}
|
2014-01-28 07:43:24 +08:00
|
|
|
|
2014-11-18 03:06:59 +08:00
|
|
|
void IOHandler::SetPopped(bool b) { m_popped.SetValue(b, eBroadcastOnChange); }
|
|
|
|
|
|
|
|
void IOHandler::WaitForPop() { m_popped.WaitForValueEqualTo(true); }
|
|
|
|
|
2016-05-18 09:59:10 +08:00
|
|
|
void IOHandlerStack::PrintAsync(Stream *stream, const char *s, size_t len) {
|
2015-05-27 20:40:32 +08:00
|
|
|
if (stream) {
|
2016-05-18 09:59:10 +08:00
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
2015-05-27 20:40:32 +08:00
|
|
|
if (m_top)
|
2016-05-18 09:59:10 +08:00
|
|
|
m_top->PrintAsync(stream, s, len);
|
2020-03-02 22:24:56 +08:00
|
|
|
else
|
|
|
|
stream->Write(s, len);
|
2015-05-27 20:40:32 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-11-13 11:05:58 +08:00
|
|
|
IOHandlerConfirm::IOHandlerConfirm(Debugger &debugger, llvm::StringRef prompt,
|
2014-01-28 07:43:24 +08:00
|
|
|
bool default_response)
|
|
|
|
: IOHandlerEditline(
|
2014-11-18 03:06:59 +08:00
|
|
|
debugger, IOHandler::Type::Confirm,
|
2016-03-12 04:20:38 +08:00
|
|
|
nullptr, // nullptr editline_name means no history loaded/saved
|
2016-09-24 02:06:53 +08:00
|
|
|
llvm::StringRef(), // No prompt
|
|
|
|
llvm::StringRef(), // No continuation prompt
|
|
|
|
false, // Multi-line
|
|
|
|
false, // Don't colorize the prompt (i.e. the confirm message.)
|
2019-03-02 08:20:26 +08:00
|
|
|
0, *this, nullptr),
|
2014-01-28 07:43:24 +08:00
|
|
|
m_default_response(default_response), m_user_response(default_response) {
|
|
|
|
StreamString prompt_stream;
|
|
|
|
prompt_stream.PutCString(prompt);
|
|
|
|
if (m_default_response)
|
|
|
|
prompt_stream.Printf(": [Y/n] ");
|
|
|
|
else
|
|
|
|
prompt_stream.Printf(": [y/N] ");
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2016-09-24 02:06:53 +08:00
|
|
|
SetPrompt(prompt_stream.GetString());
|
2014-01-28 07:43:24 +08:00
|
|
|
}
|
|
|
|
|
2015-10-27 01:00:13 +08:00
|
|
|
IOHandlerConfirm::~IOHandlerConfirm() = default;
|
2014-01-28 07:43:24 +08:00
|
|
|
|
[lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and remove any undocumented/redundant return values
Summary:
We still have some leftovers of the old completion API in the internals of
LLDB that haven't been replaced by the new CompletionRequest. These leftovers
are:
* The return values (int/size_t) in all completion functions.
* Our result array that starts indexing at 1.
* `WordComplete` mode.
I didn't replace them back then because it's tricky to figure out what exactly they
are used for and the completion code is relatively untested. I finally got around
to writing more tests for the API and understanding the semantics, so I think it's
a good time to get rid of them.
A few words why those things should be removed/replaced:
* The return values are really cryptic, partly redundant and rarely documented.
They are also completely ignored by Xcode, so whatever information they contain will end up
breaking Xcode's completion mechanism. They are also partly impossible to even implement
as we assign negative values special meaning and our completion API sometimes returns size_t.
Completion functions are supposed to return -2 to rewrite the current line. We seem to use this
in some untested code path to expand the history repeat character to the full command, but
I haven't figured out why that doesn't work at the moment.
Completion functions return -1 to 'insert the completion character', but that isn't implemented
(even though we seem to activate this feature in LLDB sometimes).
All positive values have to match the number of results. This is obviously just redundant information
as the user can just look at the result list to get that information (which is what Xcode does).
* The result array that starts indexing at 1 is obviously unexpected. The first element of the array is
reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is
that we calculate this to make the life of the API caller easier, but obviously forcing people to have
1-based indices is not helpful (or even worse, forces them to manually copy the results to make it
0-based like Xcode has to do).
* The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The
idea is that we let the top-level API know that we just provided a full completion. Interestingly we
`WordComplete` is just a single bool that somehow represents all N completions. And we always
provide full completions in LLDB, so in theory it should always be true.
The only use it currently serves is providing redundant information about whether we have a single
definitive completion or not (which we already know from the number of results we get).
This patch essentially removes `WordComplete` mode and makes the result array indexed from 0.
It also removes all return values from all internal completion functions. The only non-redundant information
they contain is about rewriting the current line (which is broken), so that functionality was moved
to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)`
to do the same.
For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common
prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we
didn't even implement them in the Editline handler (e.g. -1).
I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code,
but I would prefer doing this in follow-up NFC commits
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arphaman, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D66536
llvm-svn: 369624
2019-08-22 15:41:23 +08:00
|
|
|
void IOHandlerConfirm::IOHandlerComplete(IOHandler &io_handler,
|
|
|
|
CompletionRequest &request) {
|
2019-08-22 17:02:54 +08:00
|
|
|
if (request.GetRawCursorPos() != 0)
|
|
|
|
return;
|
|
|
|
request.AddCompletion(m_default_response ? "y" : "n");
|
2014-01-28 07:43:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void IOHandlerConfirm::IOHandlerInputComplete(IOHandler &io_handler,
|
|
|
|
std::string &line) {
|
|
|
|
if (line.empty()) {
|
|
|
|
// User just hit enter, set the response to the default
|
|
|
|
m_user_response = m_default_response;
|
|
|
|
io_handler.SetIsDone(true);
|
|
|
|
return;
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2014-01-28 07:43:24 +08:00
|
|
|
if (line.size() == 1) {
|
|
|
|
switch (line[0]) {
|
|
|
|
case 'y':
|
|
|
|
case 'Y':
|
|
|
|
m_user_response = true;
|
|
|
|
io_handler.SetIsDone(true);
|
|
|
|
return;
|
|
|
|
case 'n':
|
|
|
|
case 'N':
|
|
|
|
m_user_response = false;
|
|
|
|
io_handler.SetIsDone(true);
|
2016-09-07 04:57:50 +08:00
|
|
|
return;
|
2014-01-28 07:43:24 +08:00
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
2014-01-28 07:43:24 +08:00
|
|
|
if (line == "yes" || line == "YES" || line == "Yes") {
|
|
|
|
m_user_response = true;
|
|
|
|
io_handler.SetIsDone(true);
|
|
|
|
} else if (line == "no" || line == "NO" || line == "No") {
|
|
|
|
m_user_response = false;
|
|
|
|
io_handler.SetIsDone(true);
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2014-01-28 07:43:24 +08:00
|
|
|
}
|
|
|
|
|
[lldb] Display autosuggestion part in gray if there is one possible suggestion
This is relanding D81001. The patch originally failed as on newer editline
versions it seems CC_REFRESH will move the cursor to the start of the line via
\r and then back to the original position. On older editline versions like
the one used by default on macOS, CC_REFRESH doesn't move the cursor at all.
As the patch changed the way we handle tab completion (previously we did
REDISPLAY but now we're doing CC_REFRESH), this caused a few completion tests
to receive this unexpected cursor movement in the output stream.
This patch updates those tests to also accept output that contains the specific
cursor movement commands (\r and then \x1b[XC). lldbpexpect.py received an
utility method for generating the cursor movement escape sequence.
Original summary:
I implemented autosuggestion if there is one possible suggestion.
I set the keybinds for every character. When a character is typed, Editline::TypedCharacter is called.
Then, autosuggestion part is displayed in gray, and you can actually input by typing C-k.
Editline::Autosuggest is a function for finding completion, and it is like Editline::TabCommand now, but I will add more features to it.
Testing does not work well in my environment, so I can't confirm that it goes well, sorry. I am dealing with it now.
Reviewed By: teemperor, JDevlieghere, #lldb
Differential Revision: https://reviews.llvm.org/D81001
2020-08-12 18:54:28 +08:00
|
|
|
llvm::Optional<std::string>
|
|
|
|
IOHandlerDelegate::IOHandlerSuggestion(IOHandler &io_handler,
|
|
|
|
llvm::StringRef line) {
|
|
|
|
return io_handler.GetDebugger()
|
|
|
|
.GetCommandInterpreter()
|
|
|
|
.GetAutoSuggestionForCommand(line);
|
|
|
|
}
|
|
|
|
|
[lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and remove any undocumented/redundant return values
Summary:
We still have some leftovers of the old completion API in the internals of
LLDB that haven't been replaced by the new CompletionRequest. These leftovers
are:
* The return values (int/size_t) in all completion functions.
* Our result array that starts indexing at 1.
* `WordComplete` mode.
I didn't replace them back then because it's tricky to figure out what exactly they
are used for and the completion code is relatively untested. I finally got around
to writing more tests for the API and understanding the semantics, so I think it's
a good time to get rid of them.
A few words why those things should be removed/replaced:
* The return values are really cryptic, partly redundant and rarely documented.
They are also completely ignored by Xcode, so whatever information they contain will end up
breaking Xcode's completion mechanism. They are also partly impossible to even implement
as we assign negative values special meaning and our completion API sometimes returns size_t.
Completion functions are supposed to return -2 to rewrite the current line. We seem to use this
in some untested code path to expand the history repeat character to the full command, but
I haven't figured out why that doesn't work at the moment.
Completion functions return -1 to 'insert the completion character', but that isn't implemented
(even though we seem to activate this feature in LLDB sometimes).
All positive values have to match the number of results. This is obviously just redundant information
as the user can just look at the result list to get that information (which is what Xcode does).
* The result array that starts indexing at 1 is obviously unexpected. The first element of the array is
reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is
that we calculate this to make the life of the API caller easier, but obviously forcing people to have
1-based indices is not helpful (or even worse, forces them to manually copy the results to make it
0-based like Xcode has to do).
* The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The
idea is that we let the top-level API know that we just provided a full completion. Interestingly we
`WordComplete` is just a single bool that somehow represents all N completions. And we always
provide full completions in LLDB, so in theory it should always be true.
The only use it currently serves is providing redundant information about whether we have a single
definitive completion or not (which we already know from the number of results we get).
This patch essentially removes `WordComplete` mode and makes the result array indexed from 0.
It also removes all return values from all internal completion functions. The only non-redundant information
they contain is about rewriting the current line (which is broken), so that functionality was moved
to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)`
to do the same.
For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common
prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we
didn't even implement them in the Editline handler (e.g. -1).
I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code,
but I would prefer doing this in follow-up NFC commits
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arphaman, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D66536
llvm-svn: 369624
2019-08-22 15:41:23 +08:00
|
|
|
void IOHandlerDelegate::IOHandlerComplete(IOHandler &io_handler,
|
|
|
|
CompletionRequest &request) {
|
2014-01-28 07:43:24 +08:00
|
|
|
switch (m_completion) {
|
|
|
|
case Completion::None:
|
|
|
|
break;
|
|
|
|
case Completion::LLDBCommand:
|
[lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and remove any undocumented/redundant return values
Summary:
We still have some leftovers of the old completion API in the internals of
LLDB that haven't been replaced by the new CompletionRequest. These leftovers
are:
* The return values (int/size_t) in all completion functions.
* Our result array that starts indexing at 1.
* `WordComplete` mode.
I didn't replace them back then because it's tricky to figure out what exactly they
are used for and the completion code is relatively untested. I finally got around
to writing more tests for the API and understanding the semantics, so I think it's
a good time to get rid of them.
A few words why those things should be removed/replaced:
* The return values are really cryptic, partly redundant and rarely documented.
They are also completely ignored by Xcode, so whatever information they contain will end up
breaking Xcode's completion mechanism. They are also partly impossible to even implement
as we assign negative values special meaning and our completion API sometimes returns size_t.
Completion functions are supposed to return -2 to rewrite the current line. We seem to use this
in some untested code path to expand the history repeat character to the full command, but
I haven't figured out why that doesn't work at the moment.
Completion functions return -1 to 'insert the completion character', but that isn't implemented
(even though we seem to activate this feature in LLDB sometimes).
All positive values have to match the number of results. This is obviously just redundant information
as the user can just look at the result list to get that information (which is what Xcode does).
* The result array that starts indexing at 1 is obviously unexpected. The first element of the array is
reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is
that we calculate this to make the life of the API caller easier, but obviously forcing people to have
1-based indices is not helpful (or even worse, forces them to manually copy the results to make it
0-based like Xcode has to do).
* The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The
idea is that we let the top-level API know that we just provided a full completion. Interestingly we
`WordComplete` is just a single bool that somehow represents all N completions. And we always
provide full completions in LLDB, so in theory it should always be true.
The only use it currently serves is providing redundant information about whether we have a single
definitive completion or not (which we already know from the number of results we get).
This patch essentially removes `WordComplete` mode and makes the result array indexed from 0.
It also removes all return values from all internal completion functions. The only non-redundant information
they contain is about rewriting the current line (which is broken), so that functionality was moved
to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)`
to do the same.
For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common
prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we
didn't even implement them in the Editline handler (e.g. -1).
I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code,
but I would prefer doing this in follow-up NFC commits
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arphaman, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D66536
llvm-svn: 369624
2019-08-22 15:41:23 +08:00
|
|
|
io_handler.GetDebugger().GetCommandInterpreter().HandleCompletion(request);
|
|
|
|
break;
|
|
|
|
case Completion::Expression:
|
2016-03-12 04:20:38 +08:00
|
|
|
CommandCompletions::InvokeCommonCompletionCallbacks(
|
|
|
|
io_handler.GetDebugger().GetCommandInterpreter(),
|
[lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and remove any undocumented/redundant return values
Summary:
We still have some leftovers of the old completion API in the internals of
LLDB that haven't been replaced by the new CompletionRequest. These leftovers
are:
* The return values (int/size_t) in all completion functions.
* Our result array that starts indexing at 1.
* `WordComplete` mode.
I didn't replace them back then because it's tricky to figure out what exactly they
are used for and the completion code is relatively untested. I finally got around
to writing more tests for the API and understanding the semantics, so I think it's
a good time to get rid of them.
A few words why those things should be removed/replaced:
* The return values are really cryptic, partly redundant and rarely documented.
They are also completely ignored by Xcode, so whatever information they contain will end up
breaking Xcode's completion mechanism. They are also partly impossible to even implement
as we assign negative values special meaning and our completion API sometimes returns size_t.
Completion functions are supposed to return -2 to rewrite the current line. We seem to use this
in some untested code path to expand the history repeat character to the full command, but
I haven't figured out why that doesn't work at the moment.
Completion functions return -1 to 'insert the completion character', but that isn't implemented
(even though we seem to activate this feature in LLDB sometimes).
All positive values have to match the number of results. This is obviously just redundant information
as the user can just look at the result list to get that information (which is what Xcode does).
* The result array that starts indexing at 1 is obviously unexpected. The first element of the array is
reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is
that we calculate this to make the life of the API caller easier, but obviously forcing people to have
1-based indices is not helpful (or even worse, forces them to manually copy the results to make it
0-based like Xcode has to do).
* The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The
idea is that we let the top-level API know that we just provided a full completion. Interestingly we
`WordComplete` is just a single bool that somehow represents all N completions. And we always
provide full completions in LLDB, so in theory it should always be true.
The only use it currently serves is providing redundant information about whether we have a single
definitive completion or not (which we already know from the number of results we get).
This patch essentially removes `WordComplete` mode and makes the result array indexed from 0.
It also removes all return values from all internal completion functions. The only non-redundant information
they contain is about rewriting the current line (which is broken), so that functionality was moved
to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)`
to do the same.
For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common
prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we
didn't even implement them in the Editline handler (e.g. -1).
I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code,
but I would prefer doing this in follow-up NFC commits
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arphaman, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D66536
llvm-svn: 369624
2019-08-22 15:41:23 +08:00
|
|
|
CommandCompletions::eVariablePathCompletion, request, nullptr);
|
|
|
|
break;
|
2014-01-28 07:43:24 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
IOHandlerEditline::IOHandlerEditline(
|
2014-11-18 03:06:59 +08:00
|
|
|
Debugger &debugger, IOHandler::Type type,
|
2014-01-28 07:43:24 +08:00
|
|
|
const char *editline_name, // Used for saving history files
|
2016-09-24 02:06:53 +08:00
|
|
|
llvm::StringRef prompt, llvm::StringRef continuation_prompt,
|
|
|
|
bool multi_line, bool color_prompts, uint32_t line_number_start,
|
2019-03-02 08:20:26 +08:00
|
|
|
IOHandlerDelegate &delegate, repro::DataRecorder *data_recorder)
|
2014-01-28 07:43:24 +08:00
|
|
|
: IOHandlerEditline(debugger, type,
|
remove File::SetStream(), make new files instead.
Summary:
This patch removes File::SetStream() and File::SetDescriptor(),
and replaces most direct uses of File with pointers to File.
Instead of calling SetStream() on a file, we make a new file and
replace it.
My ultimate goal here is to introduce a new API class SBFile, which
has full support for python io.IOStream file objects. These can
redirect read() and write() to python code, so lldb::Files will
need a way to dispatch those methods. Additionally it will need some
form of sharing and assigning files, as a SBFile will be passed in and
assigned to the main IO streams of the debugger.
In my prototype patch queue, I make File itself copyable and add a
secondary class FileOps to manage the sharing and dispatch. In that
case SBFile was a unique_ptr<File>.
(here: https://github.com/smoofra/llvm-project/tree/files)
However in review, Pavel Labath suggested that it be shared_ptr instead.
(here: https://reviews.llvm.org/D67793)
In order for SBFile to use shared_ptr<File>, everything else should
as well.
If this patch is accepted, I will make SBFile use a shared_ptr
I will remove FileOps from future patches and use subclasses of File
instead.
Reviewers: JDevlieghere, jasonmolenda, zturner, jingham, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67891
llvm-svn: 373090
2019-09-27 22:33:35 +08:00
|
|
|
FileSP(), // Inherit input from top input reader
|
2014-01-28 07:43:24 +08:00
|
|
|
StreamFileSP(), // Inherit output from top input reader
|
|
|
|
StreamFileSP(), // Inherit error from top input reader
|
2014-02-06 01:57:57 +08:00
|
|
|
0, // Flags
|
2014-01-28 07:43:24 +08:00
|
|
|
editline_name, // Used for saving history files
|
2016-03-12 04:20:38 +08:00
|
|
|
prompt, continuation_prompt, multi_line, color_prompts,
|
2019-03-02 08:20:26 +08:00
|
|
|
line_number_start, delegate, data_recorder) {}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2014-01-28 07:43:24 +08:00
|
|
|
IOHandlerEditline::IOHandlerEditline(
|
remove File::SetStream(), make new files instead.
Summary:
This patch removes File::SetStream() and File::SetDescriptor(),
and replaces most direct uses of File with pointers to File.
Instead of calling SetStream() on a file, we make a new file and
replace it.
My ultimate goal here is to introduce a new API class SBFile, which
has full support for python io.IOStream file objects. These can
redirect read() and write() to python code, so lldb::Files will
need a way to dispatch those methods. Additionally it will need some
form of sharing and assigning files, as a SBFile will be passed in and
assigned to the main IO streams of the debugger.
In my prototype patch queue, I make File itself copyable and add a
secondary class FileOps to manage the sharing and dispatch. In that
case SBFile was a unique_ptr<File>.
(here: https://github.com/smoofra/llvm-project/tree/files)
However in review, Pavel Labath suggested that it be shared_ptr instead.
(here: https://reviews.llvm.org/D67793)
In order for SBFile to use shared_ptr<File>, everything else should
as well.
If this patch is accepted, I will make SBFile use a shared_ptr
I will remove FileOps from future patches and use subclasses of File
instead.
Reviewers: JDevlieghere, jasonmolenda, zturner, jingham, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67891
llvm-svn: 373090
2019-09-27 22:33:35 +08:00
|
|
|
Debugger &debugger, IOHandler::Type type, const lldb::FileSP &input_sp,
|
|
|
|
const lldb::StreamFileSP &output_sp, const lldb::StreamFileSP &error_sp,
|
|
|
|
uint32_t flags,
|
2014-01-28 07:43:24 +08:00
|
|
|
const char *editline_name, // Used for saving history files
|
2016-09-24 02:06:53 +08:00
|
|
|
llvm::StringRef prompt, llvm::StringRef continuation_prompt,
|
|
|
|
bool multi_line, bool color_prompts, uint32_t line_number_start,
|
2019-03-02 08:20:26 +08:00
|
|
|
IOHandlerDelegate &delegate, repro::DataRecorder *data_recorder)
|
|
|
|
: IOHandler(debugger, type, input_sp, output_sp, error_sp, flags,
|
|
|
|
data_recorder),
|
2019-12-13 01:22:34 +08:00
|
|
|
#if LLDB_ENABLE_LIBEDIT
|
2019-02-13 14:25:41 +08:00
|
|
|
m_editline_up(),
|
2014-09-28 00:54:22 +08:00
|
|
|
#endif
|
2014-11-18 03:06:59 +08:00
|
|
|
m_delegate(delegate), m_prompt(), m_continuation_prompt(),
|
2014-03-07 08:53:24 +08:00
|
|
|
m_current_lines_ptr(nullptr), m_base_line_number(line_number_start),
|
2014-11-18 03:06:59 +08:00
|
|
|
m_curr_line_idx(UINT32_MAX), m_multi_line(multi_line),
|
|
|
|
m_color_prompts(color_prompts), m_interrupt_exits(true),
|
Added a new command in ProcessGDBRemote that can figure out the performance characterisitics of your GDB remote server.
To addess this, attach to any GDB server and when stopped type:
(lldb) process plugin packet speed-test
The default will send a variety of packets with different amounts of data to send/receive and print the performance of each packet type:
Testing sending 1000 packets of various sizes:
qSpeedTest(send=0 , recv=0 ) in 0.057837000 sec for 17289.97 packets/sec ( 0.057837 ms per packet) with standard deviation of 0.007705 ms
qSpeedTest(send=0 , recv=4 ) in 0.056162000 sec for 17805.63 packets/sec ( 0.056162 ms per packet) with standard deviation of 0.004439 ms
qSpeedTest(send=0 , recv=8 ) in 0.057687000 sec for 17334.93 packets/sec ( 0.057687 ms per packet) with standard deviation of 0.008135 ms
qSpeedTest(send=0 , recv=16 ) in 0.058547000 sec for 17080.29 packets/sec ( 0.058547 ms per packet) with standard deviation of 0.005884 ms
qSpeedTest(send=0 , recv=32 ) in 0.058289000 sec for 17155.89 packets/sec ( 0.058289 ms per packet) with standard deviation of 0.004057 ms
qSpeedTest(send=0 , recv=64 ) in 0.061324000 sec for 16306.83 packets/sec ( 0.061324 ms per packet) with standard deviation of 0.010838 ms
qSpeedTest(send=0 , recv=128 ) in 0.065688000 sec for 15223.48 packets/sec ( 0.065688 ms per packet) with standard deviation of 0.006997 ms
qSpeedTest(send=0 , recv=256 ) in 0.070621000 sec for 14160.09 packets/sec ( 0.070621 ms per packet) with standard deviation of 0.006188 ms
qSpeedTest(send=0 , recv=512 ) in 0.086738000 sec for 11528.97 packets/sec ( 0.086738 ms per packet) with standard deviation of 0.007867 ms
qSpeedTest(send=0 , recv=1024 ) in 0.146375000 sec for 6831.77 packets/sec ( 0.146375 ms per packet) with standard deviation of 0.010313 ms
qSpeedTest(send=4 , recv=0 ) in 0.057807000 sec for 17298.94 packets/sec ( 0.057807 ms per packet) with standard deviation of 0.009702 ms
....
It will then also use various sizes to receive 4MB of data from the GDB server and print out the stats:
Testing receiving 4.0MB of data using varying receive packet sizes:
qSpeedTest(send=0 , recv=32 ) 131072 packets needed to receive 4.0MB in 7.721290000 sec for 0.518048 MB/sec for 16975.40 packets/sec ( 0.058909 ms per packet)
qSpeedTest(send=0 , recv=64 ) 65536 packets needed to receive 4.0MB in 4.029236000 sec for 0.992744 MB/sec for 16265.12 packets/sec ( 0.061481 ms per packet)
qSpeedTest(send=0 , recv=128 ) 32768 packets needed to receive 4.0MB in 2.233854000 sec for 1.790627 MB/sec for 14668.82 packets/sec ( 0.068172 ms per packet)
qSpeedTest(send=0 , recv=256 ) 16384 packets needed to receive 4.0MB in 1.160024000 sec for 3.448204 MB/sec for 14123.84 packets/sec ( 0.070802 ms per packet)
qSpeedTest(send=0 , recv=512 ) 8192 packets needed to receive 4.0MB in 0.701603000 sec for 5.701230 MB/sec for 11676.12 packets/sec ( 0.085645 ms per packet)
qSpeedTest(send=0 , recv=1024 ) 4096 packets needed to receive 4.0MB in 0.596786000 sec for 6.702570 MB/sec for 6863.43 packets/sec ( 0.145700 ms per packet)
There is a JSON mode so we can use this in the test suite to track GDB server performance for each platform:
(lldb) process plugin packet speed-test --json
{ "packet_speeds" : {
"num_packets" : 1000,
"results" : [
{"send_size" : 0, "recv_size" : 0, "total_time_nsec" : 64516000, "standard_deviation_nsec" : 20566 },
{"send_size" : 0, "recv_size" : 4, "total_time_nsec" : 59648000, "standard_deviation_nsec" : 10493 },
{"send_size" : 0, "recv_size" : 8, "total_time_nsec" : 56894000, "standard_deviation_nsec" : 5480 },
{"send_size" : 0, "recv_size" : 16, "total_time_nsec" : 59422000, "standard_deviation_nsec" : 6557 },
{"send_size" : 0, "recv_size" : 32, "total_time_nsec" : 61159000, "standard_deviation_nsec" : 12384 },
{"send_size" : 0, "recv_size" : 64, "total_time_nsec" : 61386000, "standard_deviation_nsec" : 9208 },
{"send_size" : 0, "recv_size" : 128, "total_time_nsec" : 64768000, "standard_deviation_nsec" : 4737 },
{"send_size" : 0, "recv_size" : 256, "total_time_nsec" : 71046000, "standard_deviation_nsec" : 5904 },
{"send_size" : 0, "recv_size" : 512, "total_time_nsec" : 87233000, "standard_deviation_nsec" : 8967 },
{"send_size" : 0, "recv_size" : 1024, "total_time_nsec" : 146629000, "standard_deviation_nsec" : 9526 },
{"send_size" : 4, "recv_size" : 0, "total_time_nsec" : 57131000, "standard_deviation_nsec" : 7884 },
{"send_size" : 4, "recv_size" : 4, "total_time_nsec" : 56772000, "standard_deviation_nsec" : 6064 },
{"send_size" : 4, "recv_size" : 8, "total_time_nsec" : 57450000, "standard_deviation_nsec" : 6341 },
{"send_size" : 4, "recv_size" : 16, "total_time_nsec" : 58279000, "standard_deviation_nsec" : 5998 },
{"send_size" : 4, "recv_size" : 32, "total_time_nsec" : 59995000, "standard_deviation_nsec" : 6294 },
{"send_size" : 4, "recv_size" : 64, "total_time_nsec" : 61632000, "standard_deviation_nsec" : 7838 },
{"send_size" : 4, "recv_size" : 128, "total_time_nsec" : 66535000, "standard_deviation_nsec" : 8026 },
{"send_size" : 4, "recv_size" : 256, "total_time_nsec" : 72754000, "standard_deviation_nsec" : 9519 },
{"send_size" : 4, "recv_size" : 512, "total_time_nsec" : 87072000, "standard_deviation_nsec" : 9268 },
{"send_size" : 4, "recv_size" : 1024, "total_time_nsec" : 147221000, "standard_deviation_nsec" : 9702 },
{"send_size" : 8, "recv_size" : 0, "total_time_nsec" : 57900000, "standard_deviation_nsec" : 7356 },
{"send_size" : 8, "recv_size" : 4, "total_time_nsec" : 58116000, "standard_deviation_nsec" : 7630 },
{"send_size" : 8, "recv_size" : 8, "total_time_nsec" : 57745000, "standard_deviation_nsec" : 8541 },
{"send_size" : 8, "recv_size" : 16, "total_time_nsec" : 59091000, "standard_deviation_nsec" : 7851 },
{"send_size" : 8, "recv_size" : 32, "total_time_nsec" : 59943000, "standard_deviation_nsec" : 6761 },
{"send_size" : 8, "recv_size" : 64, "total_time_nsec" : 62097000, "standard_deviation_nsec" : 8580 },
{"send_size" : 8, "recv_size" : 128, "total_time_nsec" : 69942000, "standard_deviation_nsec" : 16645 },
{"send_size" : 8, "recv_size" : 256, "total_time_nsec" : 72927000, "standard_deviation_nsec" : 11031 },
{"send_size" : 8, "recv_size" : 512, "total_time_nsec" : 87221000, "standard_deviation_nsec" : 8002 },
{"send_size" : 8, "recv_size" : 1024, "total_time_nsec" : 148696000, "standard_deviation_nsec" : 10383 },
{"send_size" : 16, "recv_size" : 0, "total_time_nsec" : 59890000, "standard_deviation_nsec" : 15160 },
{"send_size" : 16, "recv_size" : 4, "total_time_nsec" : 56664000, "standard_deviation_nsec" : 4650 },
{"send_size" : 16, "recv_size" : 8, "total_time_nsec" : 57574000, "standard_deviation_nsec" : 7787 },
{"send_size" : 16, "recv_size" : 16, "total_time_nsec" : 59312000, "standard_deviation_nsec" : 8104 },
{"send_size" : 16, "recv_size" : 32, "total_time_nsec" : 59764000, "standard_deviation_nsec" : 7496 },
{"send_size" : 16, "recv_size" : 64, "total_time_nsec" : 61644000, "standard_deviation_nsec" : 8331 },
{"send_size" : 16, "recv_size" : 128, "total_time_nsec" : 66476000, "standard_deviation_nsec" : 9251 },
{"send_size" : 16, "recv_size" : 256, "total_time_nsec" : 72386000, "standard_deviation_nsec" : 8627 },
{"send_size" : 16, "recv_size" : 512, "total_time_nsec" : 87810000, "standard_deviation_nsec" : 12318 },
{"send_size" : 16, "recv_size" : 1024, "total_time_nsec" : 146918000, "standard_deviation_nsec" : 11595 },
{"send_size" : 32, "recv_size" : 0, "total_time_nsec" : 56493000, "standard_deviation_nsec" : 6577 },
{"send_size" : 32, "recv_size" : 4, "total_time_nsec" : 57069000, "standard_deviation_nsec" : 5931 },
{"send_size" : 32, "recv_size" : 8, "total_time_nsec" : 57563000, "standard_deviation_nsec" : 8157 },
{"send_size" : 32, "recv_size" : 16, "total_time_nsec" : 59694000, "standard_deviation_nsec" : 6932 },
{"send_size" : 32, "recv_size" : 32, "total_time_nsec" : 60852000, "standard_deviation_nsec" : 8010 },
{"send_size" : 32, "recv_size" : 64, "total_time_nsec" : 61926000, "standard_deviation_nsec" : 8372 },
{"send_size" : 32, "recv_size" : 128, "total_time_nsec" : 66734000, "standard_deviation_nsec" : 8047 },
{"send_size" : 32, "recv_size" : 256, "total_time_nsec" : 72000000, "standard_deviation_nsec" : 8103 },
{"send_size" : 32, "recv_size" : 512, "total_time_nsec" : 88268000, "standard_deviation_nsec" : 12289 },
{"send_size" : 32, "recv_size" : 1024, "total_time_nsec" : 147946000, "standard_deviation_nsec" : 12122 },
{"send_size" : 64, "recv_size" : 0, "total_time_nsec" : 58126000, "standard_deviation_nsec" : 5895 },
{"send_size" : 64, "recv_size" : 4, "total_time_nsec" : 58927000, "standard_deviation_nsec" : 8933 },
{"send_size" : 64, "recv_size" : 8, "total_time_nsec" : 58163000, "standard_deviation_nsec" : 6663 },
{"send_size" : 64, "recv_size" : 16, "total_time_nsec" : 59901000, "standard_deviation_nsec" : 8340 },
{"send_size" : 64, "recv_size" : 32, "total_time_nsec" : 60365000, "standard_deviation_nsec" : 6319 },
{"send_size" : 64, "recv_size" : 64, "total_time_nsec" : 61776000, "standard_deviation_nsec" : 7461 },
{"send_size" : 64, "recv_size" : 128, "total_time_nsec" : 66984000, "standard_deviation_nsec" : 6810 },
{"send_size" : 64, "recv_size" : 256, "total_time_nsec" : 73913000, "standard_deviation_nsec" : 8826 },
{"send_size" : 64, "recv_size" : 512, "total_time_nsec" : 88134000, "standard_deviation_nsec" : 8356 },
{"send_size" : 64, "recv_size" : 1024, "total_time_nsec" : 146932000, "standard_deviation_nsec" : 7571 },
{"send_size" : 128, "recv_size" : 0, "total_time_nsec" : 57616000, "standard_deviation_nsec" : 6158 },
{"send_size" : 128, "recv_size" : 4, "total_time_nsec" : 59091000, "standard_deviation_nsec" : 7458 },
{"send_size" : 128, "recv_size" : 8, "total_time_nsec" : 60263000, "standard_deviation_nsec" : 11999 },
{"send_size" : 128, "recv_size" : 16, "total_time_nsec" : 59238000, "standard_deviation_nsec" : 6102 },
{"send_size" : 128, "recv_size" : 32, "total_time_nsec" : 60783000, "standard_deviation_nsec" : 6244 },
{"send_size" : 128, "recv_size" : 64, "total_time_nsec" : 62975000, "standard_deviation_nsec" : 8947 },
{"send_size" : 128, "recv_size" : 128, "total_time_nsec" : 65742000, "standard_deviation_nsec" : 5907 },
{"send_size" : 128, "recv_size" : 256, "total_time_nsec" : 72402000, "standard_deviation_nsec" : 6601 },
{"send_size" : 128, "recv_size" : 512, "total_time_nsec" : 87457000, "standard_deviation_nsec" : 9004 },
{"send_size" : 128, "recv_size" : 1024, "total_time_nsec" : 148412000, "standard_deviation_nsec" : 10532 },
{"send_size" : 256, "recv_size" : 0, "total_time_nsec" : 58705000, "standard_deviation_nsec" : 7274 },
{"send_size" : 256, "recv_size" : 4, "total_time_nsec" : 58818000, "standard_deviation_nsec" : 5453 },
{"send_size" : 256, "recv_size" : 8, "total_time_nsec" : 59451000, "standard_deviation_nsec" : 6926 },
{"send_size" : 256, "recv_size" : 16, "total_time_nsec" : 60237000, "standard_deviation_nsec" : 5781 },
{"send_size" : 256, "recv_size" : 32, "total_time_nsec" : 61456000, "standard_deviation_nsec" : 5591 },
{"send_size" : 256, "recv_size" : 64, "total_time_nsec" : 62615000, "standard_deviation_nsec" : 7588 },
{"send_size" : 256, "recv_size" : 128, "total_time_nsec" : 68554000, "standard_deviation_nsec" : 7766 },
{"send_size" : 256, "recv_size" : 256, "total_time_nsec" : 74557000, "standard_deviation_nsec" : 8748 },
{"send_size" : 256, "recv_size" : 512, "total_time_nsec" : 87929000, "standard_deviation_nsec" : 9510 },
{"send_size" : 256, "recv_size" : 1024, "total_time_nsec" : 148522000, "standard_deviation_nsec" : 11394 },
{"send_size" : 512, "recv_size" : 0, "total_time_nsec" : 59697000, "standard_deviation_nsec" : 7825 },
{"send_size" : 512, "recv_size" : 4, "total_time_nsec" : 59427000, "standard_deviation_nsec" : 5706 },
{"send_size" : 512, "recv_size" : 8, "total_time_nsec" : 59538000, "standard_deviation_nsec" : 6863 },
{"send_size" : 512, "recv_size" : 16, "total_time_nsec" : 61139000, "standard_deviation_nsec" : 7645 },
{"send_size" : 512, "recv_size" : 32, "total_time_nsec" : 62203000, "standard_deviation_nsec" : 7985 },
{"send_size" : 512, "recv_size" : 64, "total_time_nsec" : 62577000, "standard_deviation_nsec" : 8118 },
{"send_size" : 512, "recv_size" : 128, "total_time_nsec" : 68722000, "standard_deviation_nsec" : 10581 },
{"send_size" : 512, "recv_size" : 256, "total_time_nsec" : 74290000, "standard_deviation_nsec" : 8931 },
{"send_size" : 512, "recv_size" : 512, "total_time_nsec" : 88635000, "standard_deviation_nsec" : 7771 },
{"send_size" : 512, "recv_size" : 1024, "total_time_nsec" : 149589000, "standard_deviation_nsec" : 11456 },
{"send_size" : 1024, "recv_size" : 0, "total_time_nsec" : 63243000, "standard_deviation_nsec" : 6331 },
{"send_size" : 1024, "recv_size" : 4, "total_time_nsec" : 64381000, "standard_deviation_nsec" : 8372 },
{"send_size" : 1024, "recv_size" : 8, "total_time_nsec" : 63481000, "standard_deviation_nsec" : 5608 },
{"send_size" : 1024, "recv_size" : 16, "total_time_nsec" : 65549000, "standard_deviation_nsec" : 8826 },
{"send_size" : 1024, "recv_size" : 32, "total_time_nsec" : 65485000, "standard_deviation_nsec" : 6822 },
{"send_size" : 1024, "recv_size" : 64, "total_time_nsec" : 67125000, "standard_deviation_nsec" : 9829 },
{"send_size" : 1024, "recv_size" : 128, "total_time_nsec" : 72680000, "standard_deviation_nsec" : 7641 },
{"send_size" : 1024, "recv_size" : 256, "total_time_nsec" : 79206000, "standard_deviation_nsec" : 9854 },
{"send_size" : 1024, "recv_size" : 512, "total_time_nsec" : 92418000, "standard_deviation_nsec" : 9107 },
{"send_size" : 1024, "recv_size" : 1024, "total_time_nsec" : 152392000, "standard_deviation_nsec" : 11124 }
]
},
"download_speed" : {
"byte_size" : 4194304,
"results" : [
{"send_size" : 0, "recv_size" : 32, "total_time_nsec" : 7735630000 },
{"send_size" : 0, "recv_size" : 64, "total_time_nsec" : 3985169000 },
{"send_size" : 0, "recv_size" : 128, "total_time_nsec" : 2128791000 },
{"send_size" : 0, "recv_size" : 256, "total_time_nsec" : 1172077000 },
{"send_size" : 0, "recv_size" : 512, "total_time_nsec" : 703833000 },
{"send_size" : 0, "recv_size" : 1024, "total_time_nsec" : 594966000 }
]
}
}
llvm-svn: 237953
2015-05-22 04:52:06 +08:00
|
|
|
m_editing(false) {
|
2014-01-28 07:43:24 +08:00
|
|
|
SetPrompt(prompt);
|
|
|
|
|
2019-12-13 01:22:34 +08:00
|
|
|
#if LLDB_ENABLE_LIBEDIT
|
2014-02-01 02:48:46 +08:00
|
|
|
bool use_editline = false;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2019-10-10 02:43:03 +08:00
|
|
|
use_editline = GetInputFILE() && GetOutputFILE() && GetErrorFILE() &&
|
|
|
|
m_input_sp && m_input_sp->GetIsRealTerminal();
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2014-01-28 07:43:24 +08:00
|
|
|
if (use_editline) {
|
2020-06-25 08:44:33 +08:00
|
|
|
m_editline_up = std::make_unique<Editline>(editline_name, GetInputFILE(),
|
|
|
|
GetOutputFILE(), GetErrorFILE(),
|
|
|
|
m_color_prompts);
|
2019-02-13 14:25:41 +08:00
|
|
|
m_editline_up->SetIsInputCompleteCallback(IsInputCompleteCallback, this);
|
|
|
|
m_editline_up->SetAutoCompleteCallback(AutoCompleteCallback, this);
|
[lldb] Display autosuggestion part in gray if there is one possible suggestion
This is relanding D81001. The patch originally failed as on newer editline
versions it seems CC_REFRESH will move the cursor to the start of the line via
\r and then back to the original position. On older editline versions like
the one used by default on macOS, CC_REFRESH doesn't move the cursor at all.
As the patch changed the way we handle tab completion (previously we did
REDISPLAY but now we're doing CC_REFRESH), this caused a few completion tests
to receive this unexpected cursor movement in the output stream.
This patch updates those tests to also accept output that contains the specific
cursor movement commands (\r and then \x1b[XC). lldbpexpect.py received an
utility method for generating the cursor movement escape sequence.
Original summary:
I implemented autosuggestion if there is one possible suggestion.
I set the keybinds for every character. When a character is typed, Editline::TypedCharacter is called.
Then, autosuggestion part is displayed in gray, and you can actually input by typing C-k.
Editline::Autosuggest is a function for finding completion, and it is like Editline::TabCommand now, but I will add more features to it.
Testing does not work well in my environment, so I can't confirm that it goes well, sorry. I am dealing with it now.
Reviewed By: teemperor, JDevlieghere, #lldb
Differential Revision: https://reviews.llvm.org/D81001
2020-08-12 18:54:28 +08:00
|
|
|
if (debugger.GetUseAutosuggestion() && debugger.GetUseColor())
|
|
|
|
m_editline_up->SetSuggestionCallback(SuggestionCallback, this);
|
2014-11-18 03:06:59 +08:00
|
|
|
// See if the delegate supports fixing indentation
|
|
|
|
const char *indent_chars = delegate.IOHandlerGetFixIndentationCharacters();
|
|
|
|
if (indent_chars) {
|
|
|
|
// The delegate does support indentation, hook it up so when any
|
2018-05-01 00:49:04 +08:00
|
|
|
// indentation character is typed, the delegate gets a chance to fix it
|
2019-02-13 14:25:41 +08:00
|
|
|
m_editline_up->SetFixIndentationCallback(FixIndentationCallback, this,
|
2014-11-18 03:06:59 +08:00
|
|
|
indent_chars);
|
2014-01-28 07:43:24 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2014-09-28 00:54:22 +08:00
|
|
|
#endif
|
2014-11-18 03:06:59 +08:00
|
|
|
SetBaseLineNumber(m_base_line_number);
|
2016-09-24 02:06:53 +08:00
|
|
|
SetPrompt(prompt);
|
2014-11-18 03:06:59 +08:00
|
|
|
SetContinuationPrompt(continuation_prompt);
|
2014-01-28 07:43:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
IOHandlerEditline::~IOHandlerEditline() {
|
2019-12-13 01:22:34 +08:00
|
|
|
#if LLDB_ENABLE_LIBEDIT
|
2019-02-13 14:25:41 +08:00
|
|
|
m_editline_up.reset();
|
2014-09-28 00:54:22 +08:00
|
|
|
#endif
|
2014-01-28 07:43:24 +08:00
|
|
|
}
|
|
|
|
|
2014-11-18 03:06:59 +08:00
|
|
|
void IOHandlerEditline::Activate() {
|
|
|
|
IOHandler::Activate();
|
Quiet command regex instructions during batch execution
Summary:
Within .lldbinit, regex commands can be structured as a list of substitutions over
multiple lines. It's possible that this is uninentional, but it works and has
benefits.
For example:
command regex <command-name>
s/pat1/repl1/
s/pat2/repl2/
...
I use this form of `command regex` in my `~/.lldbinit`, because it makes it
clearer to write and read compared to a single line definition, because
multiline substitutions don't need to be quoted, and are broken up one per line.
However, multiline definitions result in usage instructions being printed for
each use. The result is that every time I run `lldb`, I get a dozen or more
lines of noise. With this change, the instructions are only printed when
`command regex` is invoked interactively, or from a terminal, neither of which
are true when lldb is sourcing `~/.lldbinit`.
Reviewers: clayborg, jingham
Reviewed By: clayborg
Subscribers: jdoerfert, kastiglione, xiaobai, keith, lldb-commits
Differential Revision: https://reviews.llvm.org/D48752
llvm-svn: 355793
2019-03-11 07:15:48 +08:00
|
|
|
m_delegate.IOHandlerActivated(*this, GetIsInteractive());
|
2014-11-18 03:06:59 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void IOHandlerEditline::Deactivate() {
|
|
|
|
IOHandler::Deactivate();
|
|
|
|
m_delegate.IOHandlerDeactivated(*this);
|
|
|
|
}
|
|
|
|
|
2020-05-09 06:14:14 +08:00
|
|
|
void IOHandlerEditline::TerminalSizeChanged() {
|
|
|
|
#if LLDB_ENABLE_LIBEDIT
|
2020-06-20 01:13:43 +08:00
|
|
|
if (m_editline_up)
|
|
|
|
m_editline_up->TerminalSizeChanged();
|
2020-05-09 06:14:14 +08:00
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
IOHandler: fall back on File::Read if a FILE* isn't available.
Summary:
IOHandler needs to read lines of input from a lldb::File.
The way it currently does this using, FILE*, which is something
we want to avoid now. I'd prefer to just replace the FILE* code
with calls to File::Read, but it contains an awkward and
delicate workaround specific to ctrl-C handling on windows, and
it's not clear if or how that workaround would translate to
lldb::File.
So in this patch, we use use the FILE* if it's available, and only
fall back on File::Read if that's the only option.
I think this is a reasonable approach here for two reasons. First
is that interactive terminal support is the one area where FILE*
can't be avoided. We need them for libedit and curses anyway,
and using them here as well is consistent with that pattern.
The second reason is that the comments express a hope that the
underlying windows bug that's being worked around will be fixed one
day, so hopefully when that happens, that whole path can be deleted.
Reviewers: JDevlieghere, jasonmolenda, labath, lanza
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68622
llvm-svn: 374576
2019-10-12 01:43:32 +08:00
|
|
|
// Split out a line from the buffer, if there is a full one to get.
|
|
|
|
static Optional<std::string> SplitLine(std::string &line_buffer) {
|
|
|
|
size_t pos = line_buffer.find('\n');
|
|
|
|
if (pos == std::string::npos)
|
|
|
|
return None;
|
2020-01-29 03:23:46 +08:00
|
|
|
std::string line =
|
|
|
|
std::string(StringRef(line_buffer.c_str(), pos).rtrim("\n\r"));
|
IOHandler: fall back on File::Read if a FILE* isn't available.
Summary:
IOHandler needs to read lines of input from a lldb::File.
The way it currently does this using, FILE*, which is something
we want to avoid now. I'd prefer to just replace the FILE* code
with calls to File::Read, but it contains an awkward and
delicate workaround specific to ctrl-C handling on windows, and
it's not clear if or how that workaround would translate to
lldb::File.
So in this patch, we use use the FILE* if it's available, and only
fall back on File::Read if that's the only option.
I think this is a reasonable approach here for two reasons. First
is that interactive terminal support is the one area where FILE*
can't be avoided. We need them for libedit and curses anyway,
and using them here as well is consistent with that pattern.
The second reason is that the comments express a hope that the
underlying windows bug that's being worked around will be fixed one
day, so hopefully when that happens, that whole path can be deleted.
Reviewers: JDevlieghere, jasonmolenda, labath, lanza
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68622
llvm-svn: 374576
2019-10-12 01:43:32 +08:00
|
|
|
line_buffer = line_buffer.substr(pos + 1);
|
|
|
|
return line;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If the final line of the file ends without a end-of-line, return
|
|
|
|
// it as a line anyway.
|
|
|
|
static Optional<std::string> SplitLineEOF(std::string &line_buffer) {
|
2020-06-20 01:17:24 +08:00
|
|
|
if (llvm::all_of(line_buffer, llvm::isSpace))
|
IOHandler: fall back on File::Read if a FILE* isn't available.
Summary:
IOHandler needs to read lines of input from a lldb::File.
The way it currently does this using, FILE*, which is something
we want to avoid now. I'd prefer to just replace the FILE* code
with calls to File::Read, but it contains an awkward and
delicate workaround specific to ctrl-C handling on windows, and
it's not clear if or how that workaround would translate to
lldb::File.
So in this patch, we use use the FILE* if it's available, and only
fall back on File::Read if that's the only option.
I think this is a reasonable approach here for two reasons. First
is that interactive terminal support is the one area where FILE*
can't be avoided. We need them for libedit and curses anyway,
and using them here as well is consistent with that pattern.
The second reason is that the comments express a hope that the
underlying windows bug that's being worked around will be fixed one
day, so hopefully when that happens, that whole path can be deleted.
Reviewers: JDevlieghere, jasonmolenda, labath, lanza
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68622
llvm-svn: 374576
2019-10-12 01:43:32 +08:00
|
|
|
return None;
|
|
|
|
std::string line = std::move(line_buffer);
|
|
|
|
line_buffer.clear();
|
|
|
|
return line;
|
|
|
|
}
|
|
|
|
|
2014-05-02 08:45:31 +08:00
|
|
|
bool IOHandlerEditline::GetLine(std::string &line, bool &interrupted) {
|
2019-12-13 01:22:34 +08:00
|
|
|
#if LLDB_ENABLE_LIBEDIT
|
2019-02-13 14:25:41 +08:00
|
|
|
if (m_editline_up) {
|
2019-03-02 08:20:26 +08:00
|
|
|
bool b = m_editline_up->GetLine(line, interrupted);
|
IOHandler: fall back on File::Read if a FILE* isn't available.
Summary:
IOHandler needs to read lines of input from a lldb::File.
The way it currently does this using, FILE*, which is something
we want to avoid now. I'd prefer to just replace the FILE* code
with calls to File::Read, but it contains an awkward and
delicate workaround specific to ctrl-C handling on windows, and
it's not clear if or how that workaround would translate to
lldb::File.
So in this patch, we use use the FILE* if it's available, and only
fall back on File::Read if that's the only option.
I think this is a reasonable approach here for two reasons. First
is that interactive terminal support is the one area where FILE*
can't be avoided. We need them for libedit and curses anyway,
and using them here as well is consistent with that pattern.
The second reason is that the comments express a hope that the
underlying windows bug that's being worked around will be fixed one
day, so hopefully when that happens, that whole path can be deleted.
Reviewers: JDevlieghere, jasonmolenda, labath, lanza
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68622
llvm-svn: 374576
2019-10-12 01:43:32 +08:00
|
|
|
if (b && m_data_recorder)
|
2019-03-02 08:20:26 +08:00
|
|
|
m_data_recorder->Record(line, true);
|
|
|
|
return b;
|
IOHandler: fall back on File::Read if a FILE* isn't available.
Summary:
IOHandler needs to read lines of input from a lldb::File.
The way it currently does this using, FILE*, which is something
we want to avoid now. I'd prefer to just replace the FILE* code
with calls to File::Read, but it contains an awkward and
delicate workaround specific to ctrl-C handling on windows, and
it's not clear if or how that workaround would translate to
lldb::File.
So in this patch, we use use the FILE* if it's available, and only
fall back on File::Read if that's the only option.
I think this is a reasonable approach here for two reasons. First
is that interactive terminal support is the one area where FILE*
can't be avoided. We need them for libedit and curses anyway,
and using them here as well is consistent with that pattern.
The second reason is that the comments express a hope that the
underlying windows bug that's being worked around will be fixed one
day, so hopefully when that happens, that whole path can be deleted.
Reviewers: JDevlieghere, jasonmolenda, labath, lanza
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68622
llvm-svn: 374576
2019-10-12 01:43:32 +08:00
|
|
|
}
|
2014-09-28 00:54:22 +08:00
|
|
|
#endif
|
2016-09-07 04:57:50 +08:00
|
|
|
|
IOHandler: fall back on File::Read if a FILE* isn't available.
Summary:
IOHandler needs to read lines of input from a lldb::File.
The way it currently does this using, FILE*, which is something
we want to avoid now. I'd prefer to just replace the FILE* code
with calls to File::Read, but it contains an awkward and
delicate workaround specific to ctrl-C handling on windows, and
it's not clear if or how that workaround would translate to
lldb::File.
So in this patch, we use use the FILE* if it's available, and only
fall back on File::Read if that's the only option.
I think this is a reasonable approach here for two reasons. First
is that interactive terminal support is the one area where FILE*
can't be avoided. We need them for libedit and curses anyway,
and using them here as well is consistent with that pattern.
The second reason is that the comments express a hope that the
underlying windows bug that's being worked around will be fixed one
day, so hopefully when that happens, that whole path can be deleted.
Reviewers: JDevlieghere, jasonmolenda, labath, lanza
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68622
llvm-svn: 374576
2019-10-12 01:43:32 +08:00
|
|
|
line.clear();
|
2016-09-07 04:57:50 +08:00
|
|
|
|
IOHandler: fall back on File::Read if a FILE* isn't available.
Summary:
IOHandler needs to read lines of input from a lldb::File.
The way it currently does this using, FILE*, which is something
we want to avoid now. I'd prefer to just replace the FILE* code
with calls to File::Read, but it contains an awkward and
delicate workaround specific to ctrl-C handling on windows, and
it's not clear if or how that workaround would translate to
lldb::File.
So in this patch, we use use the FILE* if it's available, and only
fall back on File::Read if that's the only option.
I think this is a reasonable approach here for two reasons. First
is that interactive terminal support is the one area where FILE*
can't be avoided. We need them for libedit and curses anyway,
and using them here as well is consistent with that pattern.
The second reason is that the comments express a hope that the
underlying windows bug that's being worked around will be fixed one
day, so hopefully when that happens, that whole path can be deleted.
Reviewers: JDevlieghere, jasonmolenda, labath, lanza
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68622
llvm-svn: 374576
2019-10-12 01:43:32 +08:00
|
|
|
if (GetIsInteractive()) {
|
|
|
|
const char *prompt = nullptr;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
IOHandler: fall back on File::Read if a FILE* isn't available.
Summary:
IOHandler needs to read lines of input from a lldb::File.
The way it currently does this using, FILE*, which is something
we want to avoid now. I'd prefer to just replace the FILE* code
with calls to File::Read, but it contains an awkward and
delicate workaround specific to ctrl-C handling on windows, and
it's not clear if or how that workaround would translate to
lldb::File.
So in this patch, we use use the FILE* if it's available, and only
fall back on File::Read if that's the only option.
I think this is a reasonable approach here for two reasons. First
is that interactive terminal support is the one area where FILE*
can't be avoided. We need them for libedit and curses anyway,
and using them here as well is consistent with that pattern.
The second reason is that the comments express a hope that the
underlying windows bug that's being worked around will be fixed one
day, so hopefully when that happens, that whole path can be deleted.
Reviewers: JDevlieghere, jasonmolenda, labath, lanza
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68622
llvm-svn: 374576
2019-10-12 01:43:32 +08:00
|
|
|
if (m_multi_line && m_curr_line_idx > 0)
|
|
|
|
prompt = GetContinuationPrompt();
|
2016-09-07 04:57:50 +08:00
|
|
|
|
IOHandler: fall back on File::Read if a FILE* isn't available.
Summary:
IOHandler needs to read lines of input from a lldb::File.
The way it currently does this using, FILE*, which is something
we want to avoid now. I'd prefer to just replace the FILE* code
with calls to File::Read, but it contains an awkward and
delicate workaround specific to ctrl-C handling on windows, and
it's not clear if or how that workaround would translate to
lldb::File.
So in this patch, we use use the FILE* if it's available, and only
fall back on File::Read if that's the only option.
I think this is a reasonable approach here for two reasons. First
is that interactive terminal support is the one area where FILE*
can't be avoided. We need them for libedit and curses anyway,
and using them here as well is consistent with that pattern.
The second reason is that the comments express a hope that the
underlying windows bug that's being worked around will be fixed one
day, so hopefully when that happens, that whole path can be deleted.
Reviewers: JDevlieghere, jasonmolenda, labath, lanza
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68622
llvm-svn: 374576
2019-10-12 01:43:32 +08:00
|
|
|
if (prompt == nullptr)
|
|
|
|
prompt = GetPrompt();
|
|
|
|
|
|
|
|
if (prompt && prompt[0]) {
|
|
|
|
if (m_output_sp) {
|
|
|
|
m_output_sp->Printf("%s", prompt);
|
|
|
|
m_output_sp->Flush();
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
IOHandler: fall back on File::Read if a FILE* isn't available.
Summary:
IOHandler needs to read lines of input from a lldb::File.
The way it currently does this using, FILE*, which is something
we want to avoid now. I'd prefer to just replace the FILE* code
with calls to File::Read, but it contains an awkward and
delicate workaround specific to ctrl-C handling on windows, and
it's not clear if or how that workaround would translate to
lldb::File.
So in this patch, we use use the FILE* if it's available, and only
fall back on File::Read if that's the only option.
I think this is a reasonable approach here for two reasons. First
is that interactive terminal support is the one area where FILE*
can't be avoided. We need them for libedit and curses anyway,
and using them here as well is consistent with that pattern.
The second reason is that the comments express a hope that the
underlying windows bug that's being worked around will be fixed one
day, so hopefully when that happens, that whole path can be deleted.
Reviewers: JDevlieghere, jasonmolenda, labath, lanza
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68622
llvm-svn: 374576
2019-10-12 01:43:32 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
Optional<std::string> got_line = SplitLine(m_line_buffer);
|
|
|
|
|
|
|
|
if (!got_line && !m_input_sp) {
|
|
|
|
// No more input file, we are done...
|
|
|
|
SetIsDone(true);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
FILE *in = GetInputFILE();
|
|
|
|
char buffer[256];
|
|
|
|
|
|
|
|
if (!got_line && !in && m_input_sp) {
|
|
|
|
// there is no FILE*, fall back on just reading bytes from the stream.
|
|
|
|
while (!got_line) {
|
|
|
|
size_t bytes_read = sizeof(buffer);
|
|
|
|
Status error = m_input_sp->Read((void *)buffer, bytes_read);
|
|
|
|
if (error.Success() && !bytes_read) {
|
|
|
|
got_line = SplitLineEOF(m_line_buffer);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (error.Fail())
|
|
|
|
break;
|
|
|
|
m_line_buffer += StringRef(buffer, bytes_read);
|
|
|
|
got_line = SplitLine(m_line_buffer);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!got_line && in) {
|
|
|
|
m_editing = true;
|
|
|
|
while (!got_line) {
|
|
|
|
char *r = fgets(buffer, sizeof(buffer), in);
|
2019-07-17 07:01:59 +08:00
|
|
|
#ifdef _WIN32
|
IOHandler: fall back on File::Read if a FILE* isn't available.
Summary:
IOHandler needs to read lines of input from a lldb::File.
The way it currently does this using, FILE*, which is something
we want to avoid now. I'd prefer to just replace the FILE* code
with calls to File::Read, but it contains an awkward and
delicate workaround specific to ctrl-C handling on windows, and
it's not clear if or how that workaround would translate to
lldb::File.
So in this patch, we use use the FILE* if it's available, and only
fall back on File::Read if that's the only option.
I think this is a reasonable approach here for two reasons. First
is that interactive terminal support is the one area where FILE*
can't be avoided. We need them for libedit and curses anyway,
and using them here as well is consistent with that pattern.
The second reason is that the comments express a hope that the
underlying windows bug that's being worked around will be fixed one
day, so hopefully when that happens, that whole path can be deleted.
Reviewers: JDevlieghere, jasonmolenda, labath, lanza
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68622
llvm-svn: 374576
2019-10-12 01:43:32 +08:00
|
|
|
// ReadFile on Windows is supposed to set ERROR_OPERATION_ABORTED
|
|
|
|
// according to the docs on MSDN. However, this has evidently been a
|
|
|
|
// known bug since Windows 8. Therefore, we can't detect if a signal
|
|
|
|
// interrupted in the fgets. So pressing ctrl-c causes the repl to end
|
|
|
|
// and the process to exit. A temporary workaround is just to attempt to
|
|
|
|
// fgets twice until this bug is fixed.
|
|
|
|
if (r == nullptr)
|
|
|
|
r = fgets(buffer, sizeof(buffer), in);
|
|
|
|
// this is the equivalent of EINTR for Windows
|
|
|
|
if (r == nullptr && GetLastError() == ERROR_OPERATION_ABORTED)
|
|
|
|
continue;
|
2019-07-17 07:01:59 +08:00
|
|
|
#endif
|
IOHandler: fall back on File::Read if a FILE* isn't available.
Summary:
IOHandler needs to read lines of input from a lldb::File.
The way it currently does this using, FILE*, which is something
we want to avoid now. I'd prefer to just replace the FILE* code
with calls to File::Read, but it contains an awkward and
delicate workaround specific to ctrl-C handling on windows, and
it's not clear if or how that workaround would translate to
lldb::File.
So in this patch, we use use the FILE* if it's available, and only
fall back on File::Read if that's the only option.
I think this is a reasonable approach here for two reasons. First
is that interactive terminal support is the one area where FILE*
can't be avoided. We need them for libedit and curses anyway,
and using them here as well is consistent with that pattern.
The second reason is that the comments express a hope that the
underlying windows bug that's being worked around will be fixed one
day, so hopefully when that happens, that whole path can be deleted.
Reviewers: JDevlieghere, jasonmolenda, labath, lanza
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68622
llvm-svn: 374576
2019-10-12 01:43:32 +08:00
|
|
|
if (r == nullptr) {
|
|
|
|
if (ferror(in) && errno == EINTR)
|
|
|
|
continue;
|
|
|
|
if (feof(in))
|
|
|
|
got_line = SplitLineEOF(m_line_buffer);
|
|
|
|
break;
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
IOHandler: fall back on File::Read if a FILE* isn't available.
Summary:
IOHandler needs to read lines of input from a lldb::File.
The way it currently does this using, FILE*, which is something
we want to avoid now. I'd prefer to just replace the FILE* code
with calls to File::Read, but it contains an awkward and
delicate workaround specific to ctrl-C handling on windows, and
it's not clear if or how that workaround would translate to
lldb::File.
So in this patch, we use use the FILE* if it's available, and only
fall back on File::Read if that's the only option.
I think this is a reasonable approach here for two reasons. First
is that interactive terminal support is the one area where FILE*
can't be avoided. We need them for libedit and curses anyway,
and using them here as well is consistent with that pattern.
The second reason is that the comments express a hope that the
underlying windows bug that's being worked around will be fixed one
day, so hopefully when that happens, that whole path can be deleted.
Reviewers: JDevlieghere, jasonmolenda, labath, lanza
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68622
llvm-svn: 374576
2019-10-12 01:43:32 +08:00
|
|
|
m_line_buffer += buffer;
|
|
|
|
got_line = SplitLine(m_line_buffer);
|
2014-01-28 07:43:24 +08:00
|
|
|
}
|
IOHandler: fall back on File::Read if a FILE* isn't available.
Summary:
IOHandler needs to read lines of input from a lldb::File.
The way it currently does this using, FILE*, which is something
we want to avoid now. I'd prefer to just replace the FILE* code
with calls to File::Read, but it contains an awkward and
delicate workaround specific to ctrl-C handling on windows, and
it's not clear if or how that workaround would translate to
lldb::File.
So in this patch, we use use the FILE* if it's available, and only
fall back on File::Read if that's the only option.
I think this is a reasonable approach here for two reasons. First
is that interactive terminal support is the one area where FILE*
can't be avoided. We need them for libedit and curses anyway,
and using them here as well is consistent with that pattern.
The second reason is that the comments express a hope that the
underlying windows bug that's being worked around will be fixed one
day, so hopefully when that happens, that whole path can be deleted.
Reviewers: JDevlieghere, jasonmolenda, labath, lanza
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68622
llvm-svn: 374576
2019-10-12 01:43:32 +08:00
|
|
|
m_editing = false;
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
IOHandler: fall back on File::Read if a FILE* isn't available.
Summary:
IOHandler needs to read lines of input from a lldb::File.
The way it currently does this using, FILE*, which is something
we want to avoid now. I'd prefer to just replace the FILE* code
with calls to File::Read, but it contains an awkward and
delicate workaround specific to ctrl-C handling on windows, and
it's not clear if or how that workaround would translate to
lldb::File.
So in this patch, we use use the FILE* if it's available, and only
fall back on File::Read if that's the only option.
I think this is a reasonable approach here for two reasons. First
is that interactive terminal support is the one area where FILE*
can't be avoided. We need them for libedit and curses anyway,
and using them here as well is consistent with that pattern.
The second reason is that the comments express a hope that the
underlying windows bug that's being worked around will be fixed one
day, so hopefully when that happens, that whole path can be deleted.
Reviewers: JDevlieghere, jasonmolenda, labath, lanza
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68622
llvm-svn: 374576
2019-10-12 01:43:32 +08:00
|
|
|
|
|
|
|
if (got_line) {
|
|
|
|
line = got_line.getValue();
|
|
|
|
if (m_data_recorder)
|
|
|
|
m_data_recorder->Record(line, true);
|
|
|
|
}
|
|
|
|
|
|
|
|
return (bool)got_line;
|
2014-01-28 07:43:24 +08:00
|
|
|
}
|
|
|
|
|
2019-12-13 01:22:34 +08:00
|
|
|
#if LLDB_ENABLE_LIBEDIT
|
2014-11-18 03:06:59 +08:00
|
|
|
bool IOHandlerEditline::IsInputCompleteCallback(Editline *editline,
|
2014-01-28 07:43:24 +08:00
|
|
|
StringList &lines,
|
|
|
|
void *baton) {
|
|
|
|
IOHandlerEditline *editline_reader = (IOHandlerEditline *)baton;
|
2014-11-18 03:06:59 +08:00
|
|
|
return editline_reader->m_delegate.IOHandlerIsInputComplete(*editline_reader,
|
|
|
|
lines);
|
|
|
|
}
|
|
|
|
|
|
|
|
int IOHandlerEditline::FixIndentationCallback(Editline *editline,
|
|
|
|
const StringList &lines,
|
|
|
|
int cursor_position,
|
|
|
|
void *baton) {
|
|
|
|
IOHandlerEditline *editline_reader = (IOHandlerEditline *)baton;
|
|
|
|
return editline_reader->m_delegate.IOHandlerFixIndentation(
|
|
|
|
*editline_reader, lines, cursor_position);
|
2014-01-28 07:43:24 +08:00
|
|
|
}
|
|
|
|
|
[lldb] Display autosuggestion part in gray if there is one possible suggestion
This is relanding D81001. The patch originally failed as on newer editline
versions it seems CC_REFRESH will move the cursor to the start of the line via
\r and then back to the original position. On older editline versions like
the one used by default on macOS, CC_REFRESH doesn't move the cursor at all.
As the patch changed the way we handle tab completion (previously we did
REDISPLAY but now we're doing CC_REFRESH), this caused a few completion tests
to receive this unexpected cursor movement in the output stream.
This patch updates those tests to also accept output that contains the specific
cursor movement commands (\r and then \x1b[XC). lldbpexpect.py received an
utility method for generating the cursor movement escape sequence.
Original summary:
I implemented autosuggestion if there is one possible suggestion.
I set the keybinds for every character. When a character is typed, Editline::TypedCharacter is called.
Then, autosuggestion part is displayed in gray, and you can actually input by typing C-k.
Editline::Autosuggest is a function for finding completion, and it is like Editline::TabCommand now, but I will add more features to it.
Testing does not work well in my environment, so I can't confirm that it goes well, sorry. I am dealing with it now.
Reviewed By: teemperor, JDevlieghere, #lldb
Differential Revision: https://reviews.llvm.org/D81001
2020-08-12 18:54:28 +08:00
|
|
|
llvm::Optional<std::string>
|
|
|
|
IOHandlerEditline::SuggestionCallback(llvm::StringRef line, void *baton) {
|
|
|
|
IOHandlerEditline *editline_reader = static_cast<IOHandlerEditline *>(baton);
|
|
|
|
if (editline_reader)
|
|
|
|
return editline_reader->m_delegate.IOHandlerSuggestion(*editline_reader,
|
|
|
|
line);
|
|
|
|
|
|
|
|
return llvm::None;
|
|
|
|
}
|
|
|
|
|
[lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and remove any undocumented/redundant return values
Summary:
We still have some leftovers of the old completion API in the internals of
LLDB that haven't been replaced by the new CompletionRequest. These leftovers
are:
* The return values (int/size_t) in all completion functions.
* Our result array that starts indexing at 1.
* `WordComplete` mode.
I didn't replace them back then because it's tricky to figure out what exactly they
are used for and the completion code is relatively untested. I finally got around
to writing more tests for the API and understanding the semantics, so I think it's
a good time to get rid of them.
A few words why those things should be removed/replaced:
* The return values are really cryptic, partly redundant and rarely documented.
They are also completely ignored by Xcode, so whatever information they contain will end up
breaking Xcode's completion mechanism. They are also partly impossible to even implement
as we assign negative values special meaning and our completion API sometimes returns size_t.
Completion functions are supposed to return -2 to rewrite the current line. We seem to use this
in some untested code path to expand the history repeat character to the full command, but
I haven't figured out why that doesn't work at the moment.
Completion functions return -1 to 'insert the completion character', but that isn't implemented
(even though we seem to activate this feature in LLDB sometimes).
All positive values have to match the number of results. This is obviously just redundant information
as the user can just look at the result list to get that information (which is what Xcode does).
* The result array that starts indexing at 1 is obviously unexpected. The first element of the array is
reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is
that we calculate this to make the life of the API caller easier, but obviously forcing people to have
1-based indices is not helpful (or even worse, forces them to manually copy the results to make it
0-based like Xcode has to do).
* The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The
idea is that we let the top-level API know that we just provided a full completion. Interestingly we
`WordComplete` is just a single bool that somehow represents all N completions. And we always
provide full completions in LLDB, so in theory it should always be true.
The only use it currently serves is providing redundant information about whether we have a single
definitive completion or not (which we already know from the number of results we get).
This patch essentially removes `WordComplete` mode and makes the result array indexed from 0.
It also removes all return values from all internal completion functions. The only non-redundant information
they contain is about rewriting the current line (which is broken), so that functionality was moved
to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)`
to do the same.
For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common
prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we
didn't even implement them in the Editline handler (e.g. -1).
I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code,
but I would prefer doing this in follow-up NFC commits
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arphaman, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D66536
llvm-svn: 369624
2019-08-22 15:41:23 +08:00
|
|
|
void IOHandlerEditline::AutoCompleteCallback(CompletionRequest &request,
|
|
|
|
void *baton) {
|
2014-01-28 07:43:24 +08:00
|
|
|
IOHandlerEditline *editline_reader = (IOHandlerEditline *)baton;
|
|
|
|
if (editline_reader)
|
[lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and remove any undocumented/redundant return values
Summary:
We still have some leftovers of the old completion API in the internals of
LLDB that haven't been replaced by the new CompletionRequest. These leftovers
are:
* The return values (int/size_t) in all completion functions.
* Our result array that starts indexing at 1.
* `WordComplete` mode.
I didn't replace them back then because it's tricky to figure out what exactly they
are used for and the completion code is relatively untested. I finally got around
to writing more tests for the API and understanding the semantics, so I think it's
a good time to get rid of them.
A few words why those things should be removed/replaced:
* The return values are really cryptic, partly redundant and rarely documented.
They are also completely ignored by Xcode, so whatever information they contain will end up
breaking Xcode's completion mechanism. They are also partly impossible to even implement
as we assign negative values special meaning and our completion API sometimes returns size_t.
Completion functions are supposed to return -2 to rewrite the current line. We seem to use this
in some untested code path to expand the history repeat character to the full command, but
I haven't figured out why that doesn't work at the moment.
Completion functions return -1 to 'insert the completion character', but that isn't implemented
(even though we seem to activate this feature in LLDB sometimes).
All positive values have to match the number of results. This is obviously just redundant information
as the user can just look at the result list to get that information (which is what Xcode does).
* The result array that starts indexing at 1 is obviously unexpected. The first element of the array is
reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is
that we calculate this to make the life of the API caller easier, but obviously forcing people to have
1-based indices is not helpful (or even worse, forces them to manually copy the results to make it
0-based like Xcode has to do).
* The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The
idea is that we let the top-level API know that we just provided a full completion. Interestingly we
`WordComplete` is just a single bool that somehow represents all N completions. And we always
provide full completions in LLDB, so in theory it should always be true.
The only use it currently serves is providing redundant information about whether we have a single
definitive completion or not (which we already know from the number of results we get).
This patch essentially removes `WordComplete` mode and makes the result array indexed from 0.
It also removes all return values from all internal completion functions. The only non-redundant information
they contain is about rewriting the current line (which is broken), so that functionality was moved
to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)`
to do the same.
For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common
prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we
didn't even implement them in the Editline handler (e.g. -1).
I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code,
but I would prefer doing this in follow-up NFC commits
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arphaman, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D66536
llvm-svn: 369624
2019-08-22 15:41:23 +08:00
|
|
|
editline_reader->m_delegate.IOHandlerComplete(*editline_reader, request);
|
2014-01-28 07:43:24 +08:00
|
|
|
}
|
2014-09-28 00:54:22 +08:00
|
|
|
#endif
|
2014-01-28 07:43:24 +08:00
|
|
|
|
|
|
|
const char *IOHandlerEditline::GetPrompt() {
|
2019-12-13 01:22:34 +08:00
|
|
|
#if LLDB_ENABLE_LIBEDIT
|
2019-02-13 14:25:41 +08:00
|
|
|
if (m_editline_up) {
|
|
|
|
return m_editline_up->GetPrompt();
|
2014-09-28 00:54:22 +08:00
|
|
|
} else {
|
|
|
|
#endif
|
|
|
|
if (m_prompt.empty())
|
2016-03-12 04:20:38 +08:00
|
|
|
return nullptr;
|
2019-12-13 01:22:34 +08:00
|
|
|
#if LLDB_ENABLE_LIBEDIT
|
2014-09-28 00:54:22 +08:00
|
|
|
}
|
|
|
|
#endif
|
2014-01-28 07:43:24 +08:00
|
|
|
return m_prompt.c_str();
|
|
|
|
}
|
|
|
|
|
2016-09-24 02:06:53 +08:00
|
|
|
bool IOHandlerEditline::SetPrompt(llvm::StringRef prompt) {
|
2020-01-29 03:23:46 +08:00
|
|
|
m_prompt = std::string(prompt);
|
2016-09-24 02:06:53 +08:00
|
|
|
|
2019-12-13 01:22:34 +08:00
|
|
|
#if LLDB_ENABLE_LIBEDIT
|
2019-02-13 14:25:41 +08:00
|
|
|
if (m_editline_up)
|
|
|
|
m_editline_up->SetPrompt(m_prompt.empty() ? nullptr : m_prompt.c_str());
|
2014-09-28 00:54:22 +08:00
|
|
|
#endif
|
2014-01-28 07:43:24 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2014-11-18 03:06:59 +08:00
|
|
|
const char *IOHandlerEditline::GetContinuationPrompt() {
|
2016-03-12 04:20:38 +08:00
|
|
|
return (m_continuation_prompt.empty() ? nullptr
|
|
|
|
: m_continuation_prompt.c_str());
|
2014-11-18 03:06:59 +08:00
|
|
|
}
|
|
|
|
|
2016-09-24 02:06:53 +08:00
|
|
|
void IOHandlerEditline::SetContinuationPrompt(llvm::StringRef prompt) {
|
2020-01-29 03:23:46 +08:00
|
|
|
m_continuation_prompt = std::string(prompt);
|
2014-11-18 05:31:18 +08:00
|
|
|
|
2019-12-13 01:22:34 +08:00
|
|
|
#if LLDB_ENABLE_LIBEDIT
|
2019-02-13 14:25:41 +08:00
|
|
|
if (m_editline_up)
|
|
|
|
m_editline_up->SetContinuationPrompt(m_continuation_prompt.empty()
|
2016-03-12 04:20:38 +08:00
|
|
|
? nullptr
|
|
|
|
: m_continuation_prompt.c_str());
|
2014-11-18 05:31:18 +08:00
|
|
|
#endif
|
2014-11-18 03:06:59 +08:00
|
|
|
}
|
|
|
|
|
2014-03-07 08:53:24 +08:00
|
|
|
void IOHandlerEditline::SetBaseLineNumber(uint32_t line) {
|
|
|
|
m_base_line_number = line;
|
2014-11-18 03:06:59 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
uint32_t IOHandlerEditline::GetCurrentLineIndex() const {
|
2019-12-13 01:22:34 +08:00
|
|
|
#if LLDB_ENABLE_LIBEDIT
|
2019-02-13 14:25:41 +08:00
|
|
|
if (m_editline_up)
|
|
|
|
return m_editline_up->GetCurrentLine();
|
2014-09-28 00:54:22 +08:00
|
|
|
#endif
|
2014-11-18 03:06:59 +08:00
|
|
|
return m_curr_line_idx;
|
2014-03-07 08:53:24 +08:00
|
|
|
}
|
2014-11-18 03:06:59 +08:00
|
|
|
|
2014-05-02 08:45:31 +08:00
|
|
|
bool IOHandlerEditline::GetLines(StringList &lines, bool &interrupted) {
|
2014-11-18 03:06:59 +08:00
|
|
|
m_current_lines_ptr = &lines;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2014-01-28 07:43:24 +08:00
|
|
|
bool success = false;
|
2019-12-13 01:22:34 +08:00
|
|
|
#if LLDB_ENABLE_LIBEDIT
|
2019-02-13 14:25:41 +08:00
|
|
|
if (m_editline_up) {
|
|
|
|
return m_editline_up->GetLines(m_base_line_number, lines, interrupted);
|
2014-01-28 07:43:24 +08:00
|
|
|
} else {
|
2014-09-28 00:54:22 +08:00
|
|
|
#endif
|
2014-11-18 03:06:59 +08:00
|
|
|
bool done = false;
|
2017-05-12 12:51:55 +08:00
|
|
|
Status error;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2014-11-18 03:06:59 +08:00
|
|
|
while (!done) {
|
2014-03-07 08:53:24 +08:00
|
|
|
// Show line numbers if we are asked to
|
2014-01-28 07:43:24 +08:00
|
|
|
std::string line;
|
2014-03-07 08:53:24 +08:00
|
|
|
if (m_base_line_number > 0 && GetIsInteractive()) {
|
2019-10-10 05:50:52 +08:00
|
|
|
if (m_output_sp) {
|
|
|
|
m_output_sp->Printf("%u%s",
|
|
|
|
m_base_line_number + (uint32_t)lines.GetSize(),
|
|
|
|
GetPrompt() == nullptr ? " " : "");
|
|
|
|
}
|
2014-03-07 08:53:24 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2014-11-18 03:06:59 +08:00
|
|
|
m_curr_line_idx = lines.GetSize();
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2014-05-02 08:45:31 +08:00
|
|
|
bool interrupted = false;
|
2014-11-18 03:06:59 +08:00
|
|
|
if (GetLine(line, interrupted) && !interrupted) {
|
|
|
|
lines.AppendString(line);
|
|
|
|
done = m_delegate.IOHandlerIsInputComplete(*this, lines);
|
2014-01-28 07:43:24 +08:00
|
|
|
} else {
|
2014-11-18 03:06:59 +08:00
|
|
|
done = true;
|
2014-01-28 07:43:24 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
success = lines.GetSize() > 0;
|
2019-12-13 01:22:34 +08:00
|
|
|
#if LLDB_ENABLE_LIBEDIT
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2014-09-28 00:54:22 +08:00
|
|
|
#endif
|
2014-01-28 07:43:24 +08:00
|
|
|
return success;
|
|
|
|
}
|
|
|
|
|
2018-05-01 00:49:04 +08:00
|
|
|
// Each IOHandler gets to run until it is done. It should read data from the
|
|
|
|
// "in" and place output into "out" and "err and return when done.
|
2014-01-28 07:43:24 +08:00
|
|
|
void IOHandlerEditline::Run() {
|
|
|
|
std::string line;
|
|
|
|
while (IsActive()) {
|
2014-05-02 08:45:31 +08:00
|
|
|
bool interrupted = false;
|
2014-01-28 07:43:24 +08:00
|
|
|
if (m_multi_line) {
|
|
|
|
StringList lines;
|
2014-05-02 08:45:31 +08:00
|
|
|
if (GetLines(lines, interrupted)) {
|
|
|
|
if (interrupted) {
|
2014-11-18 03:06:59 +08:00
|
|
|
m_done = m_interrupt_exits;
|
|
|
|
m_delegate.IOHandlerInputInterrupted(*this, line);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2014-05-02 08:45:31 +08:00
|
|
|
} else {
|
|
|
|
line = lines.CopyList();
|
2014-11-18 03:06:59 +08:00
|
|
|
m_delegate.IOHandlerInputComplete(*this, line);
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
} else {
|
2014-11-18 03:06:59 +08:00
|
|
|
m_done = true;
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
} else {
|
2014-11-18 03:06:59 +08:00
|
|
|
if (GetLine(line, interrupted)) {
|
|
|
|
if (interrupted)
|
|
|
|
m_delegate.IOHandlerInputInterrupted(*this, line);
|
2014-01-28 07:43:24 +08:00
|
|
|
else
|
2014-11-18 03:06:59 +08:00
|
|
|
m_delegate.IOHandlerInputComplete(*this, line);
|
2014-01-28 07:43:24 +08:00
|
|
|
} else {
|
|
|
|
m_done = true;
|
|
|
|
}
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2014-01-28 07:43:24 +08:00
|
|
|
}
|
|
|
|
|
2014-02-25 06:50:57 +08:00
|
|
|
void IOHandlerEditline::Cancel() {
|
2019-12-13 01:22:34 +08:00
|
|
|
#if LLDB_ENABLE_LIBEDIT
|
2019-02-13 14:25:41 +08:00
|
|
|
if (m_editline_up)
|
|
|
|
m_editline_up->Cancel();
|
2014-09-28 00:54:22 +08:00
|
|
|
#endif
|
2014-02-25 06:50:57 +08:00
|
|
|
}
|
|
|
|
|
2014-01-28 07:43:24 +08:00
|
|
|
bool IOHandlerEditline::Interrupt() {
|
2014-05-02 08:45:31 +08:00
|
|
|
// Let the delgate handle it first
|
|
|
|
if (m_delegate.IOHandlerInterrupt(*this))
|
|
|
|
return true;
|
|
|
|
|
2019-12-13 01:22:34 +08:00
|
|
|
#if LLDB_ENABLE_LIBEDIT
|
2019-02-13 14:25:41 +08:00
|
|
|
if (m_editline_up)
|
|
|
|
return m_editline_up->Interrupt();
|
2014-09-28 00:54:22 +08:00
|
|
|
#endif
|
2014-05-02 08:45:31 +08:00
|
|
|
return false;
|
2014-01-28 07:43:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void IOHandlerEditline::GotEOF() {
|
2019-12-13 01:22:34 +08:00
|
|
|
#if LLDB_ENABLE_LIBEDIT
|
2019-02-13 14:25:41 +08:00
|
|
|
if (m_editline_up)
|
|
|
|
m_editline_up->Interrupt();
|
2014-09-28 00:54:22 +08:00
|
|
|
#endif
|
2014-01-28 07:43:24 +08:00
|
|
|
}
|
|
|
|
|
2015-05-27 20:40:32 +08:00
|
|
|
void IOHandlerEditline::PrintAsync(Stream *stream, const char *s, size_t len) {
|
2019-12-13 01:22:34 +08:00
|
|
|
#if LLDB_ENABLE_LIBEDIT
|
2019-02-13 14:25:41 +08:00
|
|
|
if (m_editline_up)
|
|
|
|
m_editline_up->PrintAsync(stream, s, len);
|
2015-05-27 20:40:32 +08:00
|
|
|
else
|
2016-03-25 04:35:03 +08:00
|
|
|
#endif
|
|
|
|
{
|
2019-09-23 20:03:56 +08:00
|
|
|
#ifdef _WIN32
|
2016-10-01 18:37:56 +08:00
|
|
|
const char *prompt = GetPrompt();
|
2016-03-25 04:35:03 +08:00
|
|
|
if (prompt) {
|
|
|
|
// Back up over previous prompt using Windows API
|
|
|
|
CONSOLE_SCREEN_BUFFER_INFO screen_buffer_info;
|
|
|
|
HANDLE console_handle = GetStdHandle(STD_OUTPUT_HANDLE);
|
|
|
|
GetConsoleScreenBufferInfo(console_handle, &screen_buffer_info);
|
|
|
|
COORD coord = screen_buffer_info.dwCursorPosition;
|
|
|
|
coord.X -= strlen(prompt);
|
|
|
|
if (coord.X < 0)
|
|
|
|
coord.X = 0;
|
|
|
|
SetConsoleCursorPosition(console_handle, coord);
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
#endif
|
2015-05-27 20:40:32 +08:00
|
|
|
IOHandler::PrintAsync(stream, s, len);
|
2019-09-23 20:03:56 +08:00
|
|
|
#ifdef _WIN32
|
2016-03-25 04:35:03 +08:00
|
|
|
if (prompt)
|
remove File::SetStream(), make new files instead.
Summary:
This patch removes File::SetStream() and File::SetDescriptor(),
and replaces most direct uses of File with pointers to File.
Instead of calling SetStream() on a file, we make a new file and
replace it.
My ultimate goal here is to introduce a new API class SBFile, which
has full support for python io.IOStream file objects. These can
redirect read() and write() to python code, so lldb::Files will
need a way to dispatch those methods. Additionally it will need some
form of sharing and assigning files, as a SBFile will be passed in and
assigned to the main IO streams of the debugger.
In my prototype patch queue, I make File itself copyable and add a
secondary class FileOps to manage the sharing and dispatch. In that
case SBFile was a unique_ptr<File>.
(here: https://github.com/smoofra/llvm-project/tree/files)
However in review, Pavel Labath suggested that it be shared_ptr instead.
(here: https://reviews.llvm.org/D67793)
In order for SBFile to use shared_ptr<File>, everything else should
as well.
If this patch is accepted, I will make SBFile use a shared_ptr
I will remove FileOps from future patches and use subclasses of File
instead.
Reviewers: JDevlieghere, jasonmolenda, zturner, jingham, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67891
llvm-svn: 373090
2019-09-27 22:33:35 +08:00
|
|
|
IOHandler::PrintAsync(GetOutputStreamFileSP().get(), prompt,
|
2016-03-25 04:35:03 +08:00
|
|
|
strlen(prompt));
|
2016-10-01 18:37:56 +08:00
|
|
|
#endif
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2015-05-27 20:40:32 +08:00
|
|
|
}
|