[cfe-commits] [cfe-dev] [PATCH] Adding a specific_attribute_reverse_iterator

[Alexandros Tzannes]

Indeed, the reverse iterator is not intended as a solution to a problem, 
but as useful functionality in the absence of a solution (and because 
the solution is likely to take a long time to be implemented). Also, is 
there a disadvantage in having the reverse iterator functionality?

At the micro level, NULL is not a valid value for objects of type 
std::reverse_iterator<T>, so the compiler would not compile the code 
with RNull replaced by NULL.

Cheers!
Alex

On 11/14/2012 04:48 PM, Jordan Rose wrote:
> I hate to say it, but trying to solve the attributes-on-types problem 
> this way seems like a bad idea.
>
> int [[attr1]] * [[attr2, attr3]] var;
> int [[attr1, attr2]] * [[attr3]] var;
>
> We should be able to distinguish those, but we don't. And this won't 
> help us do that, and pretending that it does is not a good thing, IMHO.
>
> Jordan
>
> P.S. At the micro level, what's wrong with using NULL as the 
> reverse_iterator sentinel?
>
>
> On Nov 14, 2012, at 14:00 , Alexandros Tzannes <atzannes at illinois.edu 
> <mailto:atzannes at illinois.edu>> wrote:
>
>>  Hi all,
>> the current Clang implementation has a 
>> specific_attr_iterator<AttrType> that allows iterating over the  
>> attributes of a certain type (all attributes are kept in a single 
>> llvm::SmallVector), but it lacks a reverse iterator. This patch adds 
>> this functionality.
>>
>> Why is this useful/needed (in the short run).
>> -----------------------------------------------------------
>> The C++11 standard allows attributes to appertain to types and 
>> portions of the declarator, e.g.:
>> int[[attr1] *[[attr2] *[[attr3] var;
>>
>> However, Clang is still collapsing those attributes on the 
>> declaration itself:
>> int **var [[attr1,attr2,attr3]].
>>
>> According to C++11 when multiple attributes of the same kind 
>> appertain to the same "node", their order is irrelevant (note that 
>> these attributes may have different attribute parameters):
>>
>> int var [[attrA("x"), attrA("y")]]
>> and
>> int var [[attrA("y"), attrA("x")]]
>>
>> must mean the same thing.
>>
>> However, until attributes are allowed to appertain to all the new 
>> locations described by C++11, it would be useful to use their order 
>> to "map" them onto the  different nodes they should appertain. The 
>> specific_attr_reverse_iterator provides some functionality towards 
>> that goal.
>>
>> Implementation
>> ----------------------
>> The implementation is a slightly modified version of the code of the 
>> corresponding forward iterator. A small difference is that the 
>> forward iterator returns a pointer to the underlying type *T, whereas 
>> the reverse one returns an object of type typedef 
>> std::reverse_iterator<iterator 
>> <http://llvm.org/docs/doxygen/html/classllvm_1_1SmallVectorTemplateCommon.html#a309d93eaafb8f5a8dfb7de2a231335ea>>. 
>> For that reason, Decl::attr_rbegin() and Decl::attr_rend() for 
>> attr_reverse_iterator check if the Decl has attributes, and if so, 
>> return the begin or the end; otherwise, they return a sentinel RNull, 
>> which is implemented as a static member of Decl.
>>
>> Using the RNull sentinel is a bit awkward. Two alternatives are the 
>> following:
>> 1. Make the user responsible of checking if a Decl has an attributes 
>> vector before trying to get a specific_attr_reverse_iterator. Trying 
>> to get such an iterator on a Decl without any attrs will generate an 
>> assertion failure. This approach gets rid of RNull, but requires 
>> users to treat fwd and reverse iterators differently.
>>
>> 2. Each time the user tries to get a reverse iterator on a Decl 
>> without attributes, create an empty attribute vector and return the 
>> beginning (or the end) of it. This approach also removes the awkward 
>> RNull, but may create many unneeded empty attribute vectors.
>>
>> Please let me know if one of these alternatives is preferable.
>>
>> Cheers!
>> Alex Tzannes
>>
>> [[written during the Hacker Lab at last week's LLVM devellopers' 
>> meeting]]
>>
>> <specific_attr_reverse_iterator.diff>_______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu <mailto:cfe-dev at cs.uiuc.edu>
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20121114/ea096699/attachment.html>