That’s great! I’m happy to suggest some beginner projects, but keep in mind that it’s easy to underestimate the amount of work that even seemingly simple changes take in order to do right thing on all platforms and in all environments, so don’t get frustrated if something I suggest here turns out to be a lot more work than it looked like.
One thing we are doing in LLDB recently is improve the accuracy of LLDB’s diagnostics and error reporting. A fairly mechanical part of this is to replace APIs that either return std::optional or just a bool with ones that return llvm::Expected, for example in [lldb] Upgrade CompilerType::GetBitSize to return llvm::Expected by adrian-prantl · Pull Request #129601 · llvm/llvm-project · GitHub I’m doing this for CompilerType::getBitSize(). Each of these patches is pushing the boundary of where errors are handled further outward. But there are still plenty of (internal) APIs that maybe receive and error and then drop it, and these often should be replaced with APIs that return the error wrapped in Expected instead of logging it or ignoring it.
So for example changing
uint64_t ValueObject::GetData(DataExtractor &data, Status &error) {
into
llvm::Expected<DataExtractor> ValueObject::GetData() {
could be an easy and useful refactor (the DataExtractor already knows its size). Or it might be really difficulty and we all learn something 