Commit Graph

1216 Commits

Author SHA1 Message Date
Raphael Isemann 00efeae34f [lldb][NFC] Simplify Materializer/Dematerializer constructors 2020-01-28 11:31:02 +01:00
Igor Kudrin 9a952fd462 [LLDB] Fix build failures after removing Version from DWARFExpression. 2020-01-27 19:33:34 +07:00
Raphael Isemann 808142876c [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 08:52:55 +01:00
Adrian Prantl f55ab6f90b Fix a buffer-size bug when the first DW_OP_piece is undefined
and document the shortcomings of LLDB's partially defined DW_OP_piece
handling.

This would manifest as "DW_OP_piece for offset foo but top of stack is
of size bar".

rdar://problem/46262998

Differential Revision: https://reviews.llvm.org/D72880
2020-01-16 16:47:59 -08:00
Adrian Prantl 7b0d58e339 Add testing for DW_OP_piece and fix a bug with small Scalar values.
By switching to Scalars that are backed by explicitly-sized APInts we
can avoid a bug that increases the buffer reserved for a small piece
to the next-largest host integer type.

This manifests as "DW_OP_piece for offset foo but top of stack is of size bar".

Differential Revision: https://reviews.llvm.org/D72879
2020-01-16 16:47:36 -08:00
Adrian Prantl c0d909a1b1 Delete control character from comment. (NFC) 2020-01-16 10:44:07 -08:00
Jonas Devlieghere 7ce2de2ce4 [lldb/Debugger] Rename IO handler methods to be more meaningful (NFC)
Make it clear form the method names whether they are synchronous or
asynchronous.
2020-01-15 14:58:16 -08:00
Raphael Isemann f18370fe0e [lldb] Don't defend against internal LLVM errors in IRInterpreter
Summary:
Whenever we cast an LLVM instruction to one of its subclasses, we do a double check if the RTTI
enum value actually allows us to cast the class. I don't see a way this can ever happen as even when
LLVM's RTTI system has some corrupt internal state (which we probably should not test in the first
place) we just reuse LLVM RTTI to do the second check.

This also means that if we ever make an actual programming error in this function (e.g., have a enum
value and then cast it to a different subclass), we just silently fall back to the JIT in our tests.

We also can't test this code in any reasonable way.

This removes the checks and uses `llvm::cast` instead which will raise a fatal error when casting fails.

Reviewers: labath, mib

Reviewed By: labath

Subscribers: abidh, JDevlieghere, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D72596
2020-01-14 09:55:34 +01:00
Raphael Isemann af4adb07cd [lldb][NFC] Use range-based for loops in IRInterpreter 2020-01-13 11:58:45 +01:00
Adrian Prantl e9331a56fe Add missing nullptr checks.
GetPersistentExpressionStateForLanguage() can return a nullptr if it
cannot construct a typesystem. This patch adds missing nullptr checks
at all uses.

Inspired by rdar://problem/58317195

Differential Revision: https://reviews.llvm.org/D72413
2020-01-10 08:52:46 -08:00
Pavel Labath cd5da94d80 [lldb/DWARF] Fix mixed v4+v5 location lists
Summary:
Our code was expecting that a single (symbol) file contains only one
kind of location lists. This is not correct (on non-apple platforms, at
least) as a file can compile units with different dwarf versions.

This patch moves the deteremination of location list flavour down to the
compile unit level, fixing this problem. I have also tried to rougly
align the code with the llvm DWARFUnit. Fully matching the API is not
possible because of how lldb's DWARFExpression lives separately from the
rest of the DWARF code, but this is at least a step in the right
direction.

Reviewers: JDevlieghere, aprantl, clayborg

Subscribers: dblaikie, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D71751
2020-01-09 13:19:29 +01:00
Davide Italiano 6c87623615 [UserExpression] Clean up `return` after `else`. 2020-01-03 16:52:10 -08:00
Jan Kratochvil df6879ec02 [lldb] Fix ARM32 inferior calls
echo -e '#include <unistd.h>\nint main(void){\nsync();return 0;}'|./bin/clang -g -x c -;./bin/lldb -o 'file ./a.out' -o 'b main' -o r -o 'p (void)sync()'

Actual:

  error: Expression can't be run, because there is no JIT compiled function

Expected:

  <nothing, sync() has been executed>

This patch has been checked by:
  D71707: clang-tidy: new bugprone-pointer-cast-widening
  https://reviews.llvm.org/D71707

Casting from 32-bit `void *` to `uint64_t` requires an intermediate `uintptr_t` cast otherwise the pointer gets sign-extended:

  echo -e '#include <stdio.h>\n#include <stdint.h>\nint main(void){void *p=(void *)0x80000000;unsigned long long ull=(unsigned long long)p;unsigned long long ull2=(unsigned long
long)(uintptr_t)p;printf("p=%p ull=0x%llx ull2=0x%llx\\n",p,ull,ull2);return 0;}'|gcc -Wall -m32 -x c -;./a.out
  <stdin>: In function ‘main’:
  <stdin>:3:66: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  p=0x80000000 ull=0xffffffff80000000 ull2=0x80000000

With debug output:
Actual:

  IRMemoryMap::WriteMemory (0xb6ff8640, 0xffffffffb6f82158, 0x112) went to [0xb6ff8640..0xb6ff86b3)
  Code can be run in the target.
  Found function, has local address 0xffffffffb6f84000 and remote address 0xffffffffffffffff
  Couldn't disassemble function : Couldn't find code range for function _Z12$__lldb_exprPv
  Sections:
  [0xb6f84000+0x3c]->0xb6ff9020 (alignment 4, section ID 0, name .text)
  ...
  HandleCommand, command did not succeed
  error: Expression can't be run, because there is no JIT compiled function

Expected:

  IRMemoryMap::WriteMemory (0xb6ff8640, 0xb6faa15c, 0x128) went to [0xb6ff8640..0xb6ff86c3)
  IRExecutionUnit::GetRemoteAddressForLocal() found 0xb6fac000 in [0xb6fac000..0xb6fac040], and returned 0xb6ff9020 from [0xb6ff9020..0xb6ff9060].
  Code can be run in the target.
  Found function, has local address 0xb6fac000 and remote address 0xb6ff9020
  Function's code range is [0xb6ff9020+0x40]
  ...
  Function data has contents:
  0xb6ff9020: 10 4c 2d e9 08 b0 8d e2 08 d0 4d e2 00 40 a0 e1
  ...
  Function disassembly:
  0xb6ff9020: 0xe92d4c10   push   {r4, r10, r11, lr}

Differential revision: https://reviews.llvm.org/D71498
2019-12-21 11:12:17 +01:00
Pavel Labath 773b849c10 [lldb/DWARF] Switch to llvm location list parser
Summary:
This patch deletes the lldb location list parser and teaches the
DWARFExpression class to use the parser in llvm instead. I have
centralized all the places doing the parsing into a single
GetLocationExpression function.

In theory the the actual location list parsing should be covered by llvm
tests, and this glue code by our existing location list tests, but since
we don't have that many location list tests, I've tried to extend the
coverage a bit by adding some explicit dwarf5 loclist handling and a
test of the dumping code.

For DWARF4 location lists this should be NFC (modulo small differences
in error handling which should only show up on invalid inputs). In case
of DWARF5, this fixes various missing bits of functionality, most
notably, the lack of support for DW_LLE_offset_pair.

Reviewers: JDevlieghere, aprantl, clayborg

Subscribers: lldb-commits, dblaikie

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D71003
2019-12-09 13:39:10 +01:00
Pavel Labath 329008fdf1 [lldb] Improve/fix base address selection in location lists
Summary:
Lldb support base address selection entries in location lists was broken
for a long time. This wasn't noticed until llvm started producing these
kinds of entries more frequently with r374600.

In r374769, I made a quick patch which added sufficient support for them
to get the test suite to pass. However, I did not fully understand how
this code operates, and so the fix was not complete. Specifically, what
was lacking was the ability to handle modules which were not loaded at
their preferred load address (for instance, due to ASLR).

Now that I better understand how this code works, I've come to the
conclusion that the current setup does not provide enough information
to correctly process these entries. In the current setup the location
lists were parameterized by two addresses:
- the distance of the function start from the start of the compile unit.
  The purpose of this was to make the location ranges relative to the
  start of the function.
- the actual address where the function was loaded at. With this the
  function-start-relative ranges can be translated to actual memory
  locations.

The reason for the two values, instead of just one (the load bias) is (I
think) MachO, where the debug info in the object files will appear to be
relative to the address zero, but the actual code it refers to
can be moved and reordered by the linker. This means that the location
lists need to be "linked" to reflect the locations in the actual linked
file.

These two bits of information were enough to correctly process location
lists which do not contain base address selection entries (and so all
entries are relative to the CU base). However, they don't work with
them because, in theory two base address can be completely unrelated (as
can happen for instace with hot/cold function splitting, where the
linker can reorder the two pars arbitrarily).

To fix that, I split the first parameter into two:
- the compile unit base address
- the function start address, as is known in the object file

The new algorithm becomes:
- the location lists are processed as they were meant to be processed.
  The CU base address is used as the initial base address value. Base
  address selection entries can set a new base.
- the difference between the "file" and "load" function start addresses
  is used to compute the load bias. This value is added to the final
  ranges to get the actual memory location.

This algorithm is correct for non-MachO debug info, as there the
location lists correctly describe the code in the final executable, and
the dynamic linker can just move the entire module, not pieces of it. It
will also be correct for MachO if the static linker preserves relative
positions of the various parts of the location lists -- I don't know
whether it actually does that, but judging by the lack of base address
selection support in dsymutil and lldb, this isn't something that has
come up in the past.

I add a test case which simulates the ASLR scenario and demonstrates
that base address selection entries now work correctly here.

Reviewers: JDevlieghere, aprantl, clayborg

Subscribers: dblaikie, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D70532
2019-12-09 13:39:08 +01:00
Raphael Isemann 777d1f7272 [lldb] Migrate VMRange::Dump to raw_ostream 2019-12-06 10:19:20 +01:00
Pavel Labath 0d2472ff6f [lldb/IRExecutionUnit] Stop searching based on demangled names
Summary:
This was causing problems on linux, where we'd end up calling the
deleting destructor instead of a regular one (because they have the same
demangled name), making a lot of mischief in the process.

The only place where this was necessary (according to the test suite, at
least) was to call a base structor instead of a complete one, but this
is now handled in a more targeted fashion.

TestCallOverriddenMethod is now re-enabled as it now passes reliably.

Reviewers: teemperor, JDevlieghere

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D70722
2019-12-06 10:17:49 +01:00
Raphael Isemann 1462f5a4c1 [lldb][NFC] Move Address and AddressRange functions out of Stream and let them take raw_ostream
Summary:
Yet another step on the long road towards getting rid of lldb's Stream class.

We probably should just make this some kind of member of Address/AddressRange, but it seems quite often we just push
in random integers in there and this is just about getting rid of Stream and not improving arbitrary APIs.

I had to rename another `DumpAddress` function in FormatEntity that is dumping the content of an address to make Clang happy.

Reviewers: labath

Reviewed By: labath

Subscribers: JDevlieghere, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D71052
2019-12-05 14:41:33 +01:00
Pavel Labath 957d9a0335 [lldb] remove unsigned Stream::operator<< overloads
Summary:
I recently re-discovered that the unsinged stream operators of the
lldb_private::Stream class have a surprising behavior in that they print
the number in hex. This is all the more confusing because the "signed"
versions of those operators behave normally.

Now that, thanks to Raphael, each Stream class has a llvm::raw_ostream
wrapper, I think we should delete most of our formatting capabilities
and just delegate to that. This patch tests the water by just deleting
the operators with the most surprising behavior.

Most of the code using these operators was printing user_id_t values. It
wasn't fully consistent about prefixing them with "0x", but I've tried
to consistenly print it without that prefix, to make it more obviously
different from pointer values.

Reviewers: teemperor, JDevlieghere, jdoerfert

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D70241
2019-11-26 14:24:28 +01:00
Vedant Kumar 4fdbc0728d [DWARF] Handle call sites with indirect call targets
Split CallEdge into DirectCallEdge and IndirectCallEdge. Teach
DWARFExpression how to evaluate entry values in cases where the current
activation was created by an indirect call.

rdar://57094085

Differential Revision: https://reviews.llvm.org/D70100
2019-11-22 11:50:22 -08:00
Raphael Isemann 4a6d03ad0e [lldb] Add logging to IRExecutionUnit::GetStaticInitializers 2019-11-19 15:52:01 +01:00
Raphael Isemann c54d21c848 [lldb][NFC] Early exit in IRExecutionUnit::GetStaticInitializers 2019-11-19 15:06:30 +01:00
Jonas Devlieghere 8ac053eea2 [LLDB] Cleanup the DataEncoder utility. (NFC)
This commit removes unused methods from the DataEncoder class and cleans
up the API by making all the internal methods private.
2019-11-13 15:44:51 -08:00
Raphael Isemann 52f3a2faf9 [lldb][NFC] Move LLVM RTTI implementation from enum to static ID variable
Summary:
swift-lldb currently has to patch the ExpressionKind enum to add support for Swift expressions. If we implement LLVM's RTTI
with a static ID variable instead of a centralised enum we can drop that patch.

Reviewers: labath, davide

Reviewed By: labath

Subscribers: JDevlieghere, lldb-commits

Tags: #upstreaming_lldb_s_downstream_patches, #lldb

Differential Revision: https://reviews.llvm.org/D70070
2019-11-12 10:04:32 +01:00
Raphael Isemann 3011c7eb31 [lldb][NFC] Make LLVMUserExpression::DoExecute return early
The giant if-else isn't conforming to LLVM code style.
2019-10-29 15:38:35 +01:00
Adrian Prantl 1ad655e255 Modernize the rest of the Find.* API (NFC)
This patch removes the size_t return value and the append parameter
from the remainder of the Find.* functions in LLDB's internal API. As
in the previous patches, this is motivated by the fact that these
parameters aren't really used, and in the case of the append parameter
were frequently implemented incorrectly.

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

llvm-svn: 375160
2019-10-17 19:56:40 +00:00
Pavel Labath 5a8db84964 DWARFExpression: Fix/add support for (v4) debug_loc base address selection entries
The DWARFExpression is parsing the location lists in about five places.
Of those, only one actually had proper support for base address
selection entries.

Since r374600, llvm has started to produce location expressions with
base address selection entries more aggresively, which caused some tests
to fail.

This patch adds support for these entries to the places which had it
missing, fixing the failing tests. It also adds a targeted test for the
two of the three fixes, which should continue testing this functionality
even if the llvm output changes. I am not aware of a way to write a
targeted test for the third fix (DWARFExpression::Evaluate).

llvm-svn: 374769
2019-10-14 12:49:06 +00:00
Raphael Isemann 7c47b4a113 [lldb][NFC] Use unique_ptr in DiagnosticManager to express ownership
llvm-svn: 374289
2019-10-10 08:30:10 +00:00
Lawrence D'Anna 5da2bc22ba remove a smattering of isolated, unnecessary uses of FILE*
Summary:
There a a few call sites that use FILE* which are easy to
fix without disrupting anything else.

Reviewers: JDevlieghere, jasonmolenda, labath

Reviewed By: JDevlieghere, labath

Subscribers: lldb-commits

Tags: #lldb

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

llvm-svn: 374239
2019-10-09 21:50:52 +00:00
Adrian Prantl 939411c1aa Remove the is_mangled flag from Mangled and Symbol
Testing whether a name is mangled or not is extremely cheap and can be
done by looking at the first two characters. Mangled knows how to do
it. On the flip side, many call sites that currently pass in an
is_mangled determination do not know how to correctly do it (for
example, they leave out Swift mangling prefixes).

This patch removes this entry point and just forced Mangled to
determine the mangledness of a string itself.

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

llvm-svn: 374180
2019-10-09 16:22:14 +00:00
Pavel Labath 6f23a68a84 Use llvm for dumping DWARF expressions
Summary:
It uses the new ability of ABI plugins to vend llvm::MCRegisterInfo
structs (which is what is needed to turn dwarf register numbers into
strings).

Reviewers: JDevlieghere, aprantl, jasonmolenda

Subscribers: tatyana-krasnukha, lldb-commits

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

llvm-svn: 373208
2019-09-30 13:44:17 +00:00
Lawrence D'Anna 7ca15ba73f 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 14:33:35 +00:00
Lawrence D'Anna 2fce1137c7 Convert FileSystem::Open() to return Expected<FileUP>
Summary:
This patch converts FileSystem::Open from this prototype:

Status
Open(File &File, const FileSpec &file_spec, ...);

to this one:

llvm::Expected<std::unique_ptr<File>>
Open(const FileSpec &file_spec, ...);

This is beneficial on its own, as llvm::Expected is a more modern
and recommended error type than Status.  It is also a necessary step
towards https://reviews.llvm.org/D67891, and further developments
for lldb_private::File.

Reviewers: JDevlieghere, jasonmolenda, labath

Reviewed By: labath

Subscribers: mgorny, lldb-commits

Tags: #lldb

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

llvm-svn: 373003
2019-09-26 17:54:59 +00:00
Raphael Isemann 7f9ac3372c [lldb][NFC] Remove CompletionRequest::GetCursorArgument and GetRawLineUntilCursor
They both return the same result as another function (GetCursorArgumentPrefix
and GetRawLine). They were only added because the old API allowed to look
(in theory) behind the cursor position which is no longer possible.

llvm-svn: 372861
2019-09-25 12:55:30 +00:00
Vedant Kumar 21d417dc18 [DWARF] Evaluate DW_OP_entry_value
Add support for evaluating DW_OP_entry_value. This involves parsing
DW_TAG_call_site_parameter and wiring the information through to the expression
evaluator.

rdar://54496008

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

llvm-svn: 371668
2019-09-11 21:23:45 +00:00
Adrian Prantl 9b23df63ec Implement DW_OP_convert
This patch adds basic support for DW_OP_convert[1] for integer
types. Recent versions of LLVM's optimizer may insert this opcode into
DWARF expressions. DW_OP_convert is effectively a type cast operation
that takes a reference to a base type DIE (or zero) and then casts the
value at the top of the DWARF stack to that type. Internally this
works by changing the bit size of the APInt that is used as backing
storage for LLDB's DWARF stack.

I managed to write a unit test for this by implementing a mock YAML
object file / module that takes debug info sections in yaml2obj
format.

[1] Typed DWARF stack. http://www.dwarfstd.org/ShowIssue.php?issue=140425.1

<rdar://problem/48167864>

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

llvm-svn: 371532
2019-09-10 16:17:38 +00:00
Alex Langford 1dbee8f043 [Expression] Remove unused header from LLVMUserExpression
llvm-svn: 371472
2019-09-09 23:59:54 +00:00
Raphael Isemann 7841e80e79 [lldb][NFC] Remove Args::StripSpaces
This just reimplemented llvm::StringRef::[r/l]trim().

llvm-svn: 371181
2019-09-06 08:40:31 +00:00
Raphael Isemann b0ca908808 [lldb][NFC] Move Clang-specific flags to ClangUserExpression
LLVMUserExpression doesn't use these variables and they are all specific to Clang.

Also removes m_const_object as this was actually never used by anyone (and Clang
didn't report it as we assigned it in the constructor which seems to count as use).

llvm-svn: 370440
2019-08-30 07:44:29 +00:00
Pavel Labath ef82098a80 Remove DWARFExpression::LocationListSize
Summary:
The only reason for this function's existance is so that we could pass
the correct size into the DWARFExpression constructor. However, there is
no harm in passing the entire data extractor into the DWARFExpression,
since the same code is performing the size determination as well as the
subsequent parse. So, if we get malformed input or there's a bug in the
parser, we'd compute the wrong size anyway.

Additionally, reducing the number of entry points into the location list
parsing machinery makes it easier to switch the llvm debug_loc(lists)
parsers.

While inside, I added a couple of tests for invalid location list
handling.

Reviewers: JDevlieghere, clayborg

Subscribers: aprantl, javed.absar, kristof.beyls, lldb-commits

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

llvm-svn: 370373
2019-08-29 15:21:26 +00:00
Adrian Prantl 29db51dad4 Revert "[lldb] Move redundant persistent variable counter to ClangPersistentVariables"
This reverts commit r367842 since it wasn't quite as NFC as advertised
and broke Swift support.  See https://reviews.llvm.org/D46083 for the
rationale behind the original functionality.

rdar://problem/54619322

llvm-svn: 370126
2019-08-27 22:50:40 +00:00
Pavel Labath e588b8b664 DWARFExpression: Simplify class interface
Summary:
The DWARFExpression methods have a lot of arguments. This removes two of
them by removing the ability to slice the expression via two offset+size
parameters. This is a functionality that it is not always needed, and
when it is, we already have a different handy way of slicing a data
extractor which we can use instead.

Reviewers: JDevlieghere, clayborg

Subscribers: aprantl, lldb-commits

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

llvm-svn: 370027
2019-08-27 07:49:41 +00:00
Raphael Isemann ae34ed2c0d [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 07:41:23 +00:00
Raphael Isemann 2fc20f652c [lldb][NFC] Refactor remaining completion logic to use CompletionRequests
This patch moves the remaining completion functions from the
old completion API (that used several variables) to just
passing a single CompletionRequest.

This is for the most part a simple change as we just replace
the old arguments with a single CompletionRequest argument.

There are a few places where I had to create new CompletionRequests
in the called functions as CompletionRequests itself are immutable
and don't expose their internal match list anymore. This means that
if a function wanted to change the CompletionRequest or directly
access the result list, we need to work around this by creating
a new CompletionRequest and a temporary match/description list.

Preparation work for rdar://53769355

llvm-svn: 369000
2019-08-15 13:14:10 +00:00
Jonas Devlieghere a8f3ae7c9c [LLDB] Migrate llvm::make_unique to std::make_unique
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.

Differential revision: https://reviews.llvm.org/D66259

llvm-svn: 368933
2019-08-14 22:19:23 +00:00
Davide Italiano 7f9bbe0599 [CompilerType] Pass an ExecutionContextScope to GetTypeBitAlign.
llvm-svn: 368620
2019-08-12 21:49:54 +00:00
Davide Italiano 36f13e4912 [Symbol] GetTypeBitAlign() should return None in case of failure.
Summary:
And not `zero`. This is the last API needed to be converted to
an Optional<T>.

Reviewers: xiaobai, compnerd

Subscribers: lldb-commits

Tags: #lldb

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

llvm-svn: 368614
2019-08-12 20:03:19 +00:00
Raphael Isemann 8940687c6d [lldb] Remove undocumented return value from DiagnosticManager::PutString
The returned value is currently unused. It also seems to imply that
it somehow represents 'printf-style' the number of characters/bytes
written to some output stream (which is incorrect, as we only know
the actual size of the written message when we have rendered it,
e.g. via GetString and DiagnosticManagers have no associated
output stream).

llvm-svn: 368577
2019-08-12 14:11:37 +00:00
Davide Italiano e04c62bb23 [Materializer] Remove wrong SetSizeAndAlignmentFromType().
This function is unused.  It's also wrong, because it computes
the size and the alignment of the type without asking the runtime,
so it doesn't work for any language that has one (e.g. swift).

One could consider re-implementing this passing an execution scope
context, and modifying GetTypeBitAlign() to do the right thing,
but given there are no uses, it's not really useful.

llvm-svn: 368249
2019-08-08 03:15:48 +00:00
Haibo Huang c6551bf013 Detect HAVE_SYS_TYPES_H in lldb
Summary:
After rL368069 I noticed that HAVE_SYS_TYPES_H is not defined in
Platform.h, or anywhere else in lldb. This change fixes that.

Reviewers: labath

Subscribers: mgorny, lldb-commits

Tags: #lldb

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

llvm-svn: 368125
2019-08-07 06:15:01 +00:00