3 Commits

Author SHA1 Message Date
Jim Ingham
c1b07d6177 Have CommandObjectParsed check for "commands that take no arguments".
This is currently being done in an ad hoc way, and so for some
commands it isn't being checked.  We have the info to make this check,
since commands are supposed to add their arguments to the m_arguments
field of the CommandObject.  This change uses that info to check whether
the command received arguments in error.

A handful of commands weren't defining their argument types, I also had
to fix them.  And a bunch of commands were checking for arguments by
hand, so I removed those checks in favor of the CommandObject one.  That
also meant I had to change some tests that were checking for the ad hoc
error outputs.

Differential Revision: https://reviews.llvm.org/D128453
2022-06-27 15:14:41 -07:00
Dave Lee
4cc8f2a017 [lldb][tests] Automatically call compute_mydir (NFC)
Eliminate boilerplate of having each test manually assign to `mydir` by calling
`compute_mydir` in lldbtest.py.

Differential Revision: https://reviews.llvm.org/D128077
2022-06-17 14:34:49 -07:00
Raphael Isemann
9a57d1e526 [lldb] Allow dumping the state of all scratch TypeSystems
This adds the `target dump typesystem'`command which dumps the TypeSystem of the
target itself (aka the 'scratch TypeSystem'). This is similar to `target modules
dump ast` which dumps the AST of lldb::Modules associated with a selected
target.

Unlike `target modules dump ast`, the new command is not a subcommand of `target
modules dump` as it's not touching the modules of a target at all. Also unlike
`target modules dump ast` I tried to keep the implementation language-neutral,
so this patch moves our Clang `Dump` to the `TypeSystem` interface so it will
also dump the state of any future/downstream scratch TypeSystems (e.g., Swift).
That's also why the command just refers to a 'typesystem' instead of an 'ast'
(which is only how Clang is necessarily modelling the internal TypeSystem
state).

The main motivation for this patch is that I need to write some tests that check
for duplicates in the ScratchTypeSystemClang of a target. There is currently no
way to check for this at the moment (beside measuring memory consumption of
course). It's probably also useful for debugging LLDB itself.

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D111936
2021-10-19 12:05:14 +02:00