Attribute Order XFAIL

[Tyler Nowicki]

Hi Aaron,

Previously we discussed the problem of the AttributeList

>> [Tyler] There was a question about why I reversed the iteration over the attribute
>> list. The answer is that the attribute list built by ParsedAttributes stores
>> attributes in reverse order. However, this is wrong because the correct
>> order should be maintained for serialization/deserialization and error
>> reporting. So we have to iterate rbegin->rend. Ideally the ParsedAttributes
>> list should be fixed to store attributes in the order they appear but this
>> looks like a lot of work.
> 
> [Aaron] Ah, yes. That problem keeps rearing its ugly head. :-/


>> [Aaron] When you reintroduce your changes, I think I would prefer to leave the
>> iteration in its current (forward) order instead of reverse order (as
>> you have it in your patch). That's simply a bug, and working around it
>> here is likely to ensure that bug sticks around even longer. Once you
>> have introduced your changes, I'd appreciate an extra test case which
>> uses -ast-print and demonstrates the reversed order (I am okay with us
>> XFAILing that test) so that gives us a target test to use to verify
>> the fix when it does happen.
> 
> [Tyler] I’ll add the test case in a separate patch since it isn’t related to this work.

Here is an XFAILing test case for this.

Tyler

-------------- next part --------------
A non-text attachment was scrubbed...
Name: attribute_order.patch
Type: application/octet-stream
Size: 994 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140606/4d3acdf3/attachment.obj>