This patch specifies a few guidelines that our API tests should follow.
The motivations for this are twofold:
1. API tests have unexpected pitfalls that especially new contributors run into
when writing tests. To prevent the frustration of letting people figure those
pitfalls out by trial-and-error, let's just document them briefly in one place.
2. It prevents some arguing about what is the right way to write tests. I really
like to have fast and reliable API test suite, but I also don't want to be the
bogeyman that has to insist in every review that the test should be rewritten to
not launch a process for no good reason. It's much easier to just point to a
policy document.
I omitted some guidelines that I think could be controversial (e.g., the whole
"should assert message describe failure or success").
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D101153
Debugging tests sometimes involves debugging the Python source. This adds a paragraph to
the "Debugging Test Failures" section about using `pdb`, and also describes how to run
lldb commands from pdb.
Differential Revision: https://reviews.llvm.org/D99744
Right now we're using the 'content' role as default which will just render
these things as cursive (which isn't really useful for code examples). It also
prevents us from assigning a more useful default role in the future.
Bump the required SWIG version to 3. If my memory serves me well we last
bumped the required SWIG version to 2 for Python 3. At that time SWIG 3
had already been around for a while so everyone I know was already using
that.
It appears that SWIG 3 is the only version that officially supports
C++11 which we're using in the typemap. SWIG 3 was released in 2014 so I
think it's reasonable to make that the minimum required version.
https://bugs.llvm.org/show_bug.cgi?id=48685
Differential revision: https://reviews.llvm.org/D94244
This patch adds a HowTo document to lldb docs which gives instruction for
setting up a virtual environment based on QEMU emulator for LLDB testing.
Instruction in this document are tested on Arm and AArch64 targets but
can easily be duplicated for other targets supported by QEMU.
This helps test LLDB in absence for modern AArch64 features not released
in publicly available hardware till date.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D82064
Create a "Design" section for the LLDB documentation. The goal is to
have design documents that describe how the LLDB internals work.
Currently similar pages are mixed together under the "Development". The
existing pages describing the architecture, the reproducers, the
structured data plugins, and the SB API could be housed here. I hope
we'd see more pages being added here in the future.
Differential revision: https://reviews.llvm.org/D88516
The `macos-setup-codesign.sh` script has been in place for over two years. If there are no known issues, it's a good time to drop the manual steps from the docs.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D88257
This enables support for writing LLDB documentation in markdown in
addition to reStructured text. We already had documentation written in
markdown (StructuredDataPlugins and DarwinLog) which will now also be
available on the website.
Although this issue is not specific to macOS, Python (in)compatibility
comes up quite often and we've been linking users to this page. This
just adds more details for this particular scenario.
Differential revision: https://reviews.llvm.org/D82507
This adds a new target `check-lldb-reproducers` that replaces the old
`check-lldb-repro`. The latter would only run the shell tests, while
`check-lldb-reproducers` includes the API tests as well. The new target
will be used on GreenDragon.
It's still possible to run just the shell tests with reproducers,
although now that requires crafting the lit invocation yourself. The
parameters haven't changed and are the shame for the API and shell
tests:
--param lldb-run-with-repro=capture
--param lldb-run-with-repro=replay
This patch also updates the reproducer documentation.
Expand on the structure of the LLDB test suite. So far this information
has been mostly "tribal knowledge". By writing it down I hope to make it
easier to understand our test suite for anyone that's new to the
project.
Haibo told me he didn't have any issues with Python 3.8 and I was able
to confirm that. Even though we don't have bot running with 3.8, I think
it safe to mark it as supported in the docs.
Remove all beginning > from the sample commands as my accidental
copy-paste (multiple times...) will discard ./bin/llvm-lit which is
difficult to rebuild (I have to rm -rf and cmake it all again).
Differential Revision: https://reviews.llvm.org/D74296
Libxml2 is already an optional dependency. It should use the same
infrastructure as the other dependencies.
Differential revision: https://reviews.llvm.org/D72290
This is an attempt to feature the user-facing resources more
prominently on the LLDB website by calling out the tutorial and the
GDB command map wight on the start page.
I also moved the "Why a new debugger" section to the "Goals"
subpage. Given that LLDB's first release is almost a decade in the
past now, the title is a bit of an anachronism.
Lastly, I moved the Architecture sub-page from "use" to "resources",
since end-users do not care about the source code layout.
Differential Revision: https://reviews.llvm.org/D70449
This adds a page about LLDB reproducers. It describes how to use the
reproducers on the command line and lists some of the known
issues/limitations.
Differential revision: https://reviews.llvm.org/D70409
This adds a page named Caveats with a section on some of the things to
be aware of related to Python. It's a question we've seen more than once
pop up and I think it's good to have it documentation on the website.
Even though some of it might be useful to users, I still put it under
"development" because it requires some understanding of how LLDB is
built.
Differential revision: https://reviews.llvm.org/D70252
This renames the "Goals & Status" section to "Project" and the
"Resources" section to "Development". To better match this layout I've
moved the releases page under "Project".
Bruce Mitchener