The function in question is copy-pasted lots of times in DWARF-related classes. Thus it will make sense to place its implementation into the Support library.
Details
Diff Detail
Event Timeline
Can you add a test for the case where no Vals are provided? I remember something about that requiring an overload without the variadic template arguments.
Do you mean something like that the following?
logAllUnhandledErrors(createStringError("bar"), S, ""); EXPECT_EQ(S.str(), "bar\n") ;
I can add it but it will result in compiler warnings "warning: format string is not a string literal (potentially insecure) [-Wformat-security]" which is not looking good. We can temporary disable warnings for this test using compiler-specific pragmas but it will be very messy...
include/llvm/Support/Error.h | ||
---|---|---|
1125–1133 | For now I think this needs to take the std::error_code for the StringError as an argument too, rather than using inconvertibleErrorCode(). The reason for this is that using inconvertibleErrorCode breaks Error / std::error_code interoperability: any attempt to convert an Error value constructed with an inconvertibleErrorCode triggers an immediate abort. It is meant to be used explicitly, and only for code that explicitly documents that it does not support interoperability. It should not be default behavior. Given the increasingly wide adoption of Error we could talk about changing this policy, but that is a discussion we should have on the dev list where it will reach a wide audience. |
You can add an overload for the degenerate case to fix this:
Error createStringError(std::error_code EC, char const *Msg) { return make_error<StringError>(Msg, EC); }
Added overloaded version of createStringError() function which is not variadic, also added corresponding test.
For now I think this needs to take the std::error_code for the StringError as an argument too, rather than using inconvertibleErrorCode().
The reason for this is that using inconvertibleErrorCode breaks Error / std::error_code interoperability: any attempt to convert an Error value constructed with an inconvertibleErrorCode triggers an immediate abort. It is meant to be used explicitly, and only for code that explicitly documents that it does not support interoperability. It should not be default behavior.
Given the increasingly wide adoption of Error we could talk about changing this policy, but that is a discussion we should have on the dev list where it will reach a wide audience.