- User Since
- Jul 12 2012, 2:19 PM (444 w, 5 d)
Should be fixed in 18e093faf726d15f210ab4917142beec51848258. Sorry I
overlooked your comment on the previous landing of this change.
Thu, Jan 14
Wed, Jan 13
Mon, Jan 11
Fri, Jan 8
Tue, Jan 5
Dec 18 2020
The implementation looks fine to me.
Dec 17 2020
Dec 16 2020
@rnk Your thoughts on this would be appreciated.
Dec 15 2020
Dec 14 2020
Looks like the in-tree consumers are fine with being called on invalid declarations (CodeGen bails out if any errors have occurred). I don't think there's any easy way to find if out-of-tree consumers will be OK with this, but it does seem reasonable to ensure that we pass all the tag definitions to the consumer, even if they're invalid.
Dec 13 2020
Dec 12 2020
Dec 11 2020
Dec 10 2020
Rebase and fix test failure.
I'm overall pretty happy about how clean and non-invasive the changes required here are. But please make sure you don't change the encodings of u8"..." / u"..." / U"..." literals; those need to stay as UTF-8 / UTF-16 / UTF-32. Also, we should have a story for how the wide execution character set is controlled -- is it derived from the narrow execution character set, or can the two be changed independently, or ...?
- Handle @rjmccall's review feedback.
- Properly handle the case of a pack expansion into a non-pack and add tests for that.
Dec 9 2020
I don't like having new in the name of the flag; I think that's going to age badly (and I would argue it already has done; the "new pass manager" isn't really all that new any more).
Dec 8 2020
Dec 7 2020
Dec 3 2020
There are some mechanical changes we should make to our documentation too, particularly www/cxx_status.html.
Dec 2 2020
Looks good with a minor cleanup. Thanks!
Dec 1 2020
Let's just disable this broken GCC warning. IIRC, the corresponding clang warning covers the actual bugs caused by line continuation in comments, and doesn't warn if the next line begins with a //.
Nov 30 2020
Looks good. There are a few other places where we unconditionally insert dereferenceable attributes (for reference parameters / return types, and for C99's T [static] array parameters). We should presumably apply the same workaround everywhere we add dereferenceable.
Nov 29 2020
Thanks, that's very clean.
This was discussed on the original patch (https://reviews.llvm.org/D17993#inline-830995) and @jdoerfert argued that dereferenceable is correct even in NullPointerIsValid mode. Does this indicate a bug in the middle-end? If so, we should add a FIXME here to remove the workaround once the underlying bug is fixed.