- User Since
- Jun 28 2016, 8:37 AM (116 w, 4 d)
Wed, Sep 19
Does this still work with 32 bit hosts? Does PointerIntPair have 3 bits in that case? Is the alignof static_assert valid in that case?
A few drive-by comments... This is a patch with interactions I'm not sure I feel comfortable approving myself, so I'll count on @rjmccall to do so.
Thu, Sep 13
Wed, Sep 12
Mon, Sep 10
Thanks for the feedback @rsmith! I'm working through the lambda issue and a few other things, but will get to this as soon as I can.
Based on feedback from @rsmith I've been trying to get this to work with Lambdas like GCC does, though I'm quite confused about how to go about it here. It seems that the lambda definition call operator is deferred, however I'm having a hard time making sure that this happens in the "IFunc" case. I'm still working on it, but it might be a bit.
Thu, Sep 6
fix aaron's comments.
Wed, Sep 5
Tue, Sep 4
Aug 21 2018
Aug 17 2018
Aug 15 2018
Sorry about the long discussion on the comment... These bitfields are just hell on the next guy through if he doesn't have the context/knowledge of what are appropriate sizes.
Aug 14 2018
Aug 13 2018
Ah, right. I missed that the others already do it. Fine I guess...
I think that this causes UB. The Type baseclass will use the TypeBitfields active member, but this uses the TemplateSpecializationTypeBits, right? I know we take advantage of this elsewhere, but I'm tentative about this one...
Aug 9 2018
After talking to Aaron, we're going to try to use the lexical names for ALL cases. This requires a bunch of of accessory work (in order to get the Identifier from the SourceRange), so it'll be split up into a couple of commits and done separately. I'll likely do the part that gives Attr a diagnostic operator<< as an NFC change in the near future.
Aug 8 2018
Looks easy enough, just note the test issue.
Aug 7 2018
Aug 6 2018
Bump! I don't see anything here that seems questionable (and this has extensive testing), but I presume @rsmith should be the final one to approve.
Aug 3 2018
On the face, this seems to be a nice patch. Removing extra allocations and replacing them with the stack is a good thing IMO. This is clearly an example of PIMPL, which while it has its advantages, performance is typically a hit. My 2 concerns with this are:
IMO, I think this (and the next 2 numerically), show to me that we have too much dependence on the order of attributes, which all of these show is not a reliable thing to count on. I quite dislike this as well, and think this is going to lead us to chasing these same issues forever.
Aug 2 2018
@bricci : This likely needs to be moved into the bitfield section I think. We had a couple of other static-asserts that moved, so this is likely one of them.