[cfe-dev] Feature Idea: Error Message Replacing

[Sebastian Redl]

Douglas Gregor wrote:
> Hi Sebastian,
>
> On Jun 6, 2009, at 5:50 AM, Sebastian Redl wrote:
>> Because I've written this library, I know that this error really means,
>> "You haven't specialized the path_of struct for that template argument
>> you're trying to use, but this is a prerequisite." If I were a user of
>> the library, I'd have no clue.
>> I think there should be a way for the library author to communicate this
>> knowledge to the user.
>
> What do you need to do that static_assert doesn't already do?
I want to catch and explain arbitrary misuses of the library, beyond
those detectable by the type system. But I admit that static_assert +
concepts cover 95% of the use cases, so implementing this is probably
not worth it.
>> --- File: boost/property_tree/property_tree.en.ec (pseudo-syntax) ---
>> match "invalid use of incomplete type 'struct
>> boost::property_tree::path_of<{T}>'"
>> replacement "you need to specialize 'boost::property_tree::path_of' for
>> '$T' in order to use it as a property tree key"
>
> Isn't this going to be brittle, since the wording of error messages
> might change from one Clang release to another?
Yes. Part of working this out properly would be to devise a way of
making it less brittle.
>
>> Then, when I do
>>
>> boost::basic_ptree<boost::any, int> pt;
>>
>> I get the error
>>
>> error: you need to specialize 'boost::property_tree::path_of' for
>> 'boost::any' in order to use it as a property tree key
>
> This is one cool thing that static_assert can't do , because you've
> captured the type via {T} and can now use that type in the reformatted
> error message. We could do the same kind of thing through an extension
> to static_assert:
>
>   template<typename T>
>   struct path_of {
>     static_assert(always_false<T>::value, "you need to specialize
> 'boost::property_tree::path_of' for %0 in order to use it as a
> property tree key", T);
>   };
>
> A couple years back, I prototyped something like this for GCC, using
> some gross hacks in the G++ front end and a poor approximation of
> static_assert. The results looked promising, because the custom
> diagnostic can give much better information than the generic error
> message, especially if it can refer to your own instantiation.
This is awesome. We should totally forget about my proposal and
implement this instead.

Sebastian