- User Since
- Jul 17 2012, 3:26 PM (432 w, 8 h)
Sep 14 2020
Thank you for doing this!
Jul 24 2020
Jul 14 2020
Nov 22 2019
It looks like Inputs/modules_cdb.json missing from this patch?
Oct 29 2019
Can this get merged now?
Jan 23 2019
One minor request about regarding a dyn_cast, but this looks like the right approach. Thank you!
Apr 18 2018
Apr 17 2018
Feb 13 2018
Heh, I was probably thinking that one might want to produce references, but I don’t anyone does. I do think it would be valuable to make the parameters “T value” instead of “const T value”, and std::move them into place when we find a match.
Oct 24 2017
Yes, I think it's reasonable to treat instancetype as an inherited requirement. I guess the only exception would be if we had some notion of final classes or methods in Objective-C, in which case they'd be able to return a concrete type.
Sep 14 2017
Looks good to me; sorry for the delay.
Aug 10 2017
LGTM, thank you!
Jul 26 2017
I am *very* concerned about this. The optimization that avoids doing lookups within module files where we "know" we won't find anything was very important at the time it was introduced, so I'd like to understand better why it didn't make a significant difference in your benchmarks before we disable it. (Especially because of built-ins; those are Very Weird and probably modeled wrong).
Jul 5 2017
Committed as r307196 and r307197
Yes, digging into a static_assert to determine which condition caused it to fail would be quite useful QoI, and it should be fairly easy to use this mechanism to do that. We might want to dig one level deeper to give more information, e.g., static_assert(Comparable<T>) could look into the definition of Comparable<T> to see which piece of it failed.
Jul 4 2017
Jun 28 2017
Mar 29 2017
Jan 5 2017
The "!LangOpts.CPlusPlus" doesn't make sense to me. You're presumably defining this macro in C because the Objective-C runtime is usable from C, but that same logic applies to C++ code. It seems like we should be defining this macro unconditionally.
Dec 8 2016
Nov 10 2016
Nov 9 2016
I don't see a better way to do this. Nice meta programming hack.
Looks good! I appreciate the refactoring of recordNullabilitySeen
This is looking great, Jordan.
Nov 1 2016
Seem fine; I'd rename the "FIXME" to a "Note" unless you're going to pass a flag to Type::canHaveNullability to say how to classify dependent types.
Oct 19 2016
Do any of the regression tests make use of this diagnostic? They might have to change their "expected-error" checks to look for the corrected wording.
Sep 12 2016
Yep, this refactor looks good!
Ahhh, much cleaner. Thanks!
This looks great, thank you!
I don't love the fact that it makes callers fragile, but having to do tentative parsing for these otherwise-unambiguous cases is expensive (in compile time). We should only use tentative parsing when we have an actual ambiguity to resolve.
Aug 25 2016
This will work, but it's *really* unfortunate to put tentative parsing into this code path because tentative parsing is far from free, and specialized Objective-C types are getting pretty common in Objective-C headers. Why can't the callers be taught to handle EOF and bail out?
Aug 23 2016
Aug 19 2016
I think most of the complexity here will fold away when ObjCTypeParamType becomes sugar for the underlying ObjCObjectPointerType.
A couple of comments above, but this is looking very good.
This refactor LGTM.