llvm-project/lldb/source/Utility/CompletionRequest.cpp
Raphael Isemann 1a6d7ab55d Narrow the CompletionRequest API to being append-only.
Summary:
We currently allow any completion handler to read and manipulate the list of matches we
calculated so far. This leads to a few problems:

Firstly, a completion handler's logic can now depend on previously calculated results
by another handlers. No completion handler should have such an implicit dependency,
but the current API makes it likely that this could happen (or already happens). Especially
the fact that some completion handler deleted all previously calculated results can mess
things up right now.

Secondly, all completion handlers have knowledge about our internal data structures with
this API. This makes refactoring this internal data structure much harder than it should be.
Especially planned changes like the support of descriptions for completions are currently
giant patches because we have to refactor every single completion handler.

This patch narrows the contract the CompletionRequest has with the different handlers to:

1. A handler can suggest a completion.
2. A handler can ask how many suggestions we already have.

Point 2 obviously means we still have a  dependency left between the different handlers, but
getting rid of this is too large to just append it to this patch.

Otherwise this patch just completely hides the internal StringList to the different handlers.

The CompletionRequest API now also ensures that the list of completions is unique and we
don't suggest the same value multiple times to the user. This property has been so far only
been ensured by the `Option` handler, but is now applied globally. This is part of this patch
as the OptionHandler is no longer able to implement this functionality itself.

Reviewers: jingham, davide, labath

Reviewed By: davide

Subscribers: lldb-commits

Differential Revision: https://reviews.llvm.org/D49322

llvm-svn: 338151
2018-07-27 18:42:46 +00:00

61 lines
2.3 KiB
C++

//===-- CompletionRequest.cpp -----------------------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
#include "lldb/Utility/CompletionRequest.h"
using namespace lldb;
using namespace lldb_private;
CompletionRequest::CompletionRequest(llvm::StringRef command_line,
unsigned raw_cursor_pos,
int match_start_point,
int max_return_elements,
StringList &matches)
: m_command(command_line), m_raw_cursor_pos(raw_cursor_pos),
m_match_start_point(match_start_point),
m_max_return_elements(max_return_elements), m_matches(&matches) {
matches.Clear();
// We parse the argument up to the cursor, so the last argument in
// parsed_line is the one containing the cursor, and the cursor is after the
// last character.
m_parsed_line = Args(command_line);
m_partial_parsed_line = Args(command_line.substr(0, raw_cursor_pos));
m_cursor_index = m_partial_parsed_line.GetArgumentCount() - 1;
if (m_cursor_index == -1)
m_cursor_char_position = 0;
else
m_cursor_char_position =
strlen(m_partial_parsed_line.GetArgumentAtIndex(m_cursor_index));
matches.Clear();
const char *cursor = command_line.data() + raw_cursor_pos;
if (raw_cursor_pos > 0 && cursor[-1] == ' ') {
// We are just after a space. If we are in an argument, then we will
// continue parsing, but if we are between arguments, then we have to
// complete whatever the next element would be. We can distinguish the two
// cases because if we are in an argument (e.g. because the space is
// protected by a quote) then the space will also be in the parsed
// argument...
const char *current_elem =
m_partial_parsed_line.GetArgumentAtIndex(m_cursor_index);
if (m_cursor_char_position == 0 ||
current_elem[m_cursor_char_position - 1] != ' ') {
m_parsed_line.InsertArgumentAtIndex(m_cursor_index + 1, llvm::StringRef(),
'\0');
m_cursor_index++;
m_cursor_char_position = 0;
}
}
}