I suspect you're right about that. Hopefully it would be easy enough. Unfortunately, SourceLocation doesn't have an operator<, which kind of stinks. I suspect that it'll be a non-trivial thing to do, since it is actually possible to have attributes added with empty source-locations in some case, but hopefully whoever is brave enough to tackle this can figure it out.
-----Original Message----- From: Aaron Ballman [mailto:[email protected]] Sent: Friday, August 3, 2018 7:35 AM To: Keane, Erich <[email protected]> Cc: [email protected]; Michael Kruse <[email protected]>; Hal Finkel <[email protected]>; Tyler Nowicki <[email protected]>; Alexey Bataev <[email protected]>; John McCall <[email protected]>; George Burgess IV <[email protected]>; Nick Lewycky <[email protected]>; Nick Lewycky <[email protected]>; [email protected]; [email protected]; [email protected]; llvm-commits <[email protected]>; [email protected]; Richard Smith <[email protected]>; Eric Christopher <[email protected]>; [email protected]; Simon Atanasyan <[email protected]>; cfe-commits <[email protected]>; [email protected]; [email protected] Subject: Re: [PATCH] D48100: Append new attributes to the end of an AttributeList. On Fri, Aug 3, 2018 at 10:09 AM, Keane, Erich <[email protected]> wrote: >> As a possible idea (that may or may not work): the Attr object itself has a >> SourceRange on it; perhaps a solution is to keep the > attributes in sorted >> order within DeclBase::addAttr() based on the SourceRanges passed in? > > Interestingly, I think I came up with that idea in a comment on D50214. I > think that we should either keep the attributes sorted, or make the iterator > give a sorted version. Oh, hey, so you did! I think keeping them in a sorted order is preferable to having the iterator return a sorted version; I believe we iterate attribute more often than we add them because things like hasAttr<>() and getAttr<>() both rely on iterating through the attributes. ~Aaron > > > > -----Original Message----- > From: Aaron Ballman [mailto:[email protected]] > Sent: Friday, August 3, 2018 7:02 AM > To: [email protected] > Cc: Michael Kruse <[email protected]>; Hal Finkel <[email protected]>; > Tyler Nowicki <[email protected]>; Alexey Bataev > <[email protected]>; John McCall <[email protected]>; George > Burgess IV <[email protected]>; Nick Lewycky > <[email protected]>; Nick Lewycky <[email protected]>; [email protected]; > [email protected]; [email protected]; llvm-commits > <[email protected]>; [email protected]; Richard Smith > <[email protected]>; Keane, Erich <[email protected]>; Eric > Christopher <[email protected]>; [email protected]; Simon > Atanasyan <[email protected]>; cfe-commits > <[email protected]>; [email protected]; > [email protected] > Subject: Re: [PATCH] D48100: Append new attributes to the end of an > AttributeList. > > On Fri, Aug 3, 2018 at 8:53 AM, Erich Keane via Phabricator > <[email protected]> wrote: >> erichkeane added a comment. >> >> In https://reviews.llvm.org/D48100#1186654, @Meinersbur wrote: >> >>> I have two approaches to tackle the wrong marker order: >>> https://reviews.llvm.org/D50215 and https://reviews.llvm.org/D50216. IMHO >>> both are too invasive to be justified for the small issue. >> >> >> I think you're right here. I despise https://reviews.llvm.org/D50215, and >> only mostly hate https://reviews.llvm.org/D50216. I think I'd prefer >> leaving this as a "FIXME" somewhere. > > Oye, I'm in agreement that this should be fixed but that neither of these > approaches leaves me feeling warm and fuzzy. > > As a possible idea (that may or may not work): the Attr object itself has a > SourceRange on it; perhaps a solution is to keep the attributes in sorted > order within DeclBase::addAttr() based on the SourceRanges passed in? > > ~Aaron > >> >> >> Repository: >> rL LLVM >> >> https://reviews.llvm.org/D48100 >> >> >> _______________________________________________ cfe-commits mailing list [email protected] http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
