cl::ParseCommandLineOptions fails to emit some messages to the stream passed to it

Some error messages from CL are going to llvm::errs() rather than the error stream (Errs) passed to ParseCommandLineOptions.

Some of these are errors in how cl:opt is used whereas others are related to command line errors.

I am not sure about the former (those can be thought of as application internal errors) but I think the latter errors (command line processing errors) should be sent to the error stream so that the application can print the error to an appropriate stream (for example, if the application wants to output the messages to a logger stream, it should be able to do so).

For example, if an option -foo expects an integral argument and if the application command line specifies -foo=boo, the error message about expecting an integral valuie goes to llvm::errs().

The issue is that Option::error is called in a few places without the error stream argument. I think this is a bug but I want to check my understanding before submitting a patch.

Big +1 to using a stream, or some other mechanism for communicating the errors back to the client app, rather than always directly printing to llvm::errrs() (or stderr equivalently). I did a talk on error handling in libraries (see 2018 LLVM Developers’ Meeting: J. Henderson “Error Handling in Libraries: A Case Study” - YouTube) where I ran into a similar situation in the debug info library.

I think it’s okay if there’s a default option for how errors are handled that involves printing to llvm::errs() but there should be a mechanism to override this default behaviour, so that apps can opt-in.

1 Like