User Details
- User Since
- Jul 17 2012, 3:26 PM (584 w, 3 d)
Jul 20 2022
Sep 8 2021
Looks great, thank you!
Sep 7 2021
Dec 6 2020
This looks good. I went ahead and tested it as part of adoption in Swift's Clang importer, over at https://github.com/apple/swift/pull/34985
Dec 4 2020
Thank you!
Dec 2 2020
This looks great to me, thank you!
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
LGTM, thanks
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
Looks great!
Mar 29 2017
LGTM!
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
LGTM!
Nov 10 2016
Yeah, LGTM.
Nov 9 2016
I don't see a better way to do this. Nice meta programming hack.
LGTM!
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!