[Patch][ObjC][Proposal] NSValue literals
AlexDenisov
1101.debian at gmail.com
Mon Jan 19 09:55:29 PST 2015
Thank you for response, Fariborz.
Looking forward for outcome :)
--
AlexDenisov
Software Engineer, https://github.com/AlexDenisov
On 19 Jan 2015 at 18:29:51, jahanian (fjahanian at apple.com) wrote:
Sorry, yes busy and vacation. Your patch looks good to me. I have a pending proposal which pretty much
describes what is implemented (with due credit :). Let’s wait for outcome of this proposal.
- Thanks, Fariborz
On Jan 17, 2015, at 1:44 PM, AlexDenisov <1101.debian at gmail.com> wrote:
I guess you’re busy with the next LLVM/Clang release, but just want to know how is it going with this patch.
Let me know if I can help somehow.
--
AlexDenisov
Software Engineer, https://github.com/AlexDenisov
On 10 Jan 2015 at 11:12:39, AlexDenisov (1101.debian at gmail.com) wrote:
Here is new version, without pointers.
--
AlexDenisov
Software Engineer, https://github.com/AlexDenisov
On 9 Jan 2015 at 20:14:47, jahanian (fjahanian at apple.com) wrote:
We may not support boxing of any pointer types after all
(as the underlying API does not manage the collected object).
So, final patch may need to address that. Please provide more tests
for NSEdgeInsets and specifically, see that diagnostics come out when
deployment target does not support it.
Otherwise, patch looks good. Please hang on to the patch until we have gone through
the language review process.
- Thanks, Fairborz
On Jan 6, 2015, at 10:23 AM, AlexDenisov <1101.debian at gmail.com> wrote:
Thank you for response.
I already sent another patch, it could be found here:
http://article.gmane.org/gmane.comp.compilers.clang.scm/114023
--
AlexDenisov
Software Engineer, https://github.com/AlexDenisov
On 5 Jan 2015 at 19:39:16, jahanian (fjahanian at apple.com) wrote:
On Dec 24, 2014, at 3:29 AM, AlexDenisov <1101.debian at gmail.com> wrote:
Do the usual lookup to find the method which implements this syntax. Call Decl::getAvailability on this method. If it returns
anything other than AvailabilityResult::AR_Available
Well, I understand this part, it’s pretty obvious. But what I don’t understand is:
issue an appropriate diagnostic.
What is appropriate diagnostic for AR_NotYetIntroduced?
Should I introduce this diagnostic? Or just show warning/error for Deprecated/Unavailable and ignore NotYetIntroduced AR?
It is sufficient to issue an unavailability diagnostics since diagnostic points to the method which has the availability info. as part of its declaration.
- Fariborz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150119/f690c826/attachment.html>
More information about the cfe-commits
mailing list