I’m not an lldb user, but I use other libraries from the llvm ecosystem and share similar pain points.
I believe we need a wider audience and reach a conclusion with common guidance across the whole project.
In the end, the whole llvm-poject is advertised to be made of libraries [1,2], and libraries might be used in contexts where a crash might not be a desired or acceptable error reporting, let alone have UB due to the lack of having asserts in released products guarding e.g. container accesses etc.
One such use case is tooling, and I’m in particular involved with the Clang frontend component. However, even the llvm-project offers products such as clangd where I think these thoughts should also directly apply.
The liberal use of asserts [3] and the lack of handling the case when the assert is gone (like in release build), we often face UB. Downstream, we have a growing set of patches working around cases like that. For example, in Clang Sema, or in the parser language spec invariants are sometimes assumed to hold, which is fine for well-formed code, but falls short after parsing invalid code, and having recovery expression nodes. But the sentiment remains true: we might have invalid input, but it’s still undesired to just crash. The line between what is an invariant that should be always true and an assumption derived from some user input is blurry, but it’s frequently possible to handle the situation gracefully.
One example of handling it is by checking the condition, and have an assert but also having a return/continuation path basically limiting the damage. This approach worked for us, but in the end, usually, the code needs to have this in mind when designed, and hard to retrofit.
I believe, the elaborate use of asserts, as advertised in [3], and similarly unjustified llvm unreachables [4] cause significant pain for vendors building on top of the llvm-project. And I think we, as a project, should be aligned when should we use assert, and when do more sophisticated error detection/handling.
[1] GitHub project About: “The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.”
[2] llvm.org “[…] are great examples of the sort of tools that can be built using the Clang frontend as a library to parse C/C++ code.”
[3] CodingStandards.html#assert-liberally
[4] Discrourse: llvm_unreachable is widely misused