[cfe-dev] Feature Idea: Error Message Replacing

AlisdairM(public) public at alisdairm.net
Sat Jun 6 06:32:12 PDT 2009


> -----Original Message-----
> From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu]
> On Behalf Of Sebastian Redl
> Sent: 06 June 2009 13:50
> To: clang-dev Developers
> Subject: [cfe-dev] Feature Idea: Error Message Replacing
> 
> Hi,
> 
> This is a feature idea I just came up with. I have no concrete plans to
> implement this, but I thought I'd post it to the list to see if others
> like it as well, and to preserve it for future reference.
> 
> I'm currently working on a Boost library, and in the compile errors
> this
> shows up:
> 
> error: invalid use of incomplete type ‘struct
> boost::property_tree::path_of<boost::any>’
> 
> 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. I'm imagining something like this:
> 
> --- File: boost/property_tree/ptree.hpp (the library's main include) --
> -
> #pragma clang error_catalog "boost/property_tree/property_tree.en.ec"
> 
> // Users have to specialize this
> template <typename Key> struct path_of;
> 
> 
> --- 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"
> 
> 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
> 
> 
> Error catalogs would be looked up either in the include path or some
> separate lookup path; I would prefer the include path because it makes
> using error catalogs "just work" for the library user. Error catalogs
> are cumulative, i.e. you can have any number of error_catalog pragmas
> in
> a translation unit.
> 
> Comments? With C++0x concepts, the need for this is obviously smaller
> (my example is a result of a pseudo-concept emulation), but I think it
> could still be useful.
> 
> Sebastian

To an extent this is similar to an issue I would like to solve in C++0x with another standard attribute (although I suspect the time for even limited proposals is long past).  Essentially, there is a problem that template struct path_of needs to be declared purely as a means to define [partial] specializations - the primary template itself is never designed to be instantiated.  There are templates like this is in the standard library (std::function, for instance) and it would be really nice to add an attribute that says 'you must always provide a specialization for this template'.

	// Users have to specialize this
	template <typename Key> struct path_of [[not_defined]];

Now your idea here goes further with linking the lack-of-specialization to a specific library use for even better error messages - I'm not sure how my simple attribute could cover that.

AlisdairM






More information about the cfe-dev mailing list