[all-commits] [llvm/llvm-project] 1f8a32: [lldb] Only send "posix" error codes through the g...

[Adrian Prantl via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 1f8a3286e065b8cb82628db0d335b3e82b9373fd
      https://github.com/llvm/llvm-project/commit/1f8a3286e065b8cb82628db0d335b3e82b9373fd
  Author: Pavel Labath <pavel at labath.sk>
  Date:   2024-09-19 (Thu, 19 Sep 2024)

  Changed paths:
    M lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
    M lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationServerTest.cpp

  Log Message:
  -----------
  [lldb] Only send "posix" error codes through the gdb-remote protocol

The other side has no way of telling which namespace do these codes
belong to, so mashing them all together is not very helpful.

I'm mainly doing this to simplify some code in a pending patch
<https://github.com/llvm/llvm-project/pull/106774/files#r1752628604>,
and I've picked the posix error category semi-randomly. If we wanted to
be serious about assigning meaning to these error codes, we should
create a special error category for "gdb errors".


  Commit: 104b249c236578d298384416c495ff7310b97f4d
      https://github.com/llvm/llvm-project/commit/104b249c236578d298384416c495ff7310b97f4d
  Author: Adrian Prantl <aprantl at apple.com>
  Date:   2024-09-19 (Thu, 19 Sep 2024)

  Changed paths:
    M lldb/include/lldb/Utility/Status.h
    M lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
    M lldb/source/Utility/Status.cpp
    M lldb/unittests/Utility/StatusTest.cpp

  Log Message:
  -----------
  [lldb] Change the implementation of Status to store an llvm::Error (NFC) (#106774)

(based on a conversation I had with @labath yesterday in
https://github.com/llvm/llvm-project/pull/106442)

Most APIs that currently vend a Status would be better served by
returning llvm::Expected<> instead. If possibles APIs should be
refactored to avoid Status. The only legitimate long-term uses of Status
are objects that need to store an error for a long time (which should be
questioned as a design decision, too).

This patch makes the transition to llvm::Error easier by making the
places that cannot switch to llvm::Error explicit: They are marked with
a call to Status::clone(). Every other API can and should be refactored
to use llvm::Expected. In the end Status should only be used in very few
places.

Whenever an unchecked Error is dropped by Status it logs this to the
verbose API channel.

Implementation notes:

This patch introduces two new kinds of error_category as well as new
llvm::Error types. Here is the mapping of lldb::ErrorType to
llvm::Errors:
```
   (eErrorTypeInvalid)
   eErrorTypeGeneric      llvm::StringError
   eErrorTypePOSIX        llvm::ECError
   eErrorTypeMachKernel   MachKernelError
   eErrorTypeExpression   llvm::ErrorList<ExpressionError>
   eErrorTypeWin32        Win32Error
```

Relanding with built-in cloning support for llvm::ECError.


Compare: https://github.com/llvm/llvm-project/compare/beb2ae734830...104b249c2365

To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications