[cfe-commits] [PATCH] Add -fobjc-direct-class-refs
Douglas Gregor
dgregor at apple.com
Mon Jul 16 10:20:55 PDT 2012
On Jul 12, 2012, at 12:42 AM, John McCall <rjmccall at apple.com> wrote:
> On Jul 11, 2012, at 11:46 PM, David Blaikie wrote:
>> On Wed, Jul 11, 2012 at 11:36 PM, John McCall <rjmccall at apple.com> wrote:
>>> On Jul 11, 2012, at 10:17 PM, David Blaikie wrote:
>>>> On Wed, Jul 11, 2012 at 7:32 PM, Jonathan Schleifer <js at webkeks.org> wrote:
>>>>> Am 12.07.2012 um 04:21 schrieb John McCall:
>>>>>> On Jul 11, 2012, at 6:05 PM, Jonathan Schleifer wrote:
>>>>>>>
>>>>>>> Am 12.07.2012 um 02:58 schrieb John McCall:
>>>>>>>>
>>>>>>>> Subscripting on objects has an existing meaning in fragile runtimes:
>>>>>>>> it's pointer arithmetic. Is that meaning useful? Well, possibly not, but
>>>>>>>> nonetheless such code has historically been valid.
>>>>>>>
>>>>>>>
>>>>>>> As such code does not exist for ObjFW as there is not that historical
>>>>>>> part, I'd like to just forbid pointer arithmetics and allow subscripts.
>>>>>>
>>>>>>
>>>>>> That seems totally reasonable.
>>>>>
>>>>>
>>>>> Ok, then I'll add it using the way you described before.
>>>>>
>>>>>
>>>>>> I added a test case (please do include tests in your patches!) and
>>>>>> committed this as r160102.
>>>>>
>>>>>
>>>>> Nice!
>>>>>
>>>>> I'm not exactly sure as to how these tests work. From looking at the commit,
>>>>> it seems it's ObjC code with comments that first specify the command to
>>>>> compile and then define the expected in LLVM ASM?
>>>>>
>>>>>
>>>>>
>>>>>> For the record, I should establish a policy here and give you some fair
>>>>>> warning. We're happy to keep support for ObjFW in the tree as long as
>>>>>> you're maintaining your runtime. If it ever looks like it's become a dead
>>>>>> project, and we can't reach any maintainers for an extended period of time,
>>>>>> we reserve the right to strip this code out as bit-rotted. Okay?
>>>>>
>>>>>
>>>>> That sounds fair. Please contact me at this e-mail address if there are any
>>>>> questions regarding the ObjFW support. As long as you don't remove it
>>>>> without contacting me, everything is fine by me :).
>>>>
>>>> Might want to put that down in the code owners documentation and/or
>>>> authors file if you haven't already.
>>>
>>> We don't seem to have a place to put this kind of Clang-specific developer
>>> "policy statement",
>>
>> We already have multiple Clang subcategories mentioned here
>> http://llvm.org/docs/DeveloperPolicy.html#code-owners - but yeah,
>> might be a bit too fine grained for that page?
>>
>>> and it doesn't really belong in the LLVM repository.
>>
>> Hmm? We seem to describe a variety of contribution areas in the
>> contributor file (though ownership can/does differs from
>> contribution).
>>
>>> I could start a new page, or we could let the archive speak for itself.
>>
>> Yep - it was just a thought if there was a place to write it
>> down/someone felt it should be - didn't mean to initiate/create any
>> extra policy/maintenance burden.
>
>
> Oh, I think I misinterpreted you. Do you just mean we should put down
> Jonathan's name as an "owner" of the ObjFW support? We don't really
> bother to classify ownership at that fine of a level, but more importantly,
> Jonathan's not a code owner in that sense — he's not even a committer
> right now. Code ownership is about technical expertise in an area of
> the compiler's implementation, not about responsibility for its "user-level"
> design. As an analogy, we would not make Herb Sutter a code owner
> for clang's C++ support. :)
>
> If Jonathan decides to become a committer, he can add himself to
> CREDITS.TXT if he likes. Otherwise, the commit log is an adequate
> breadcrumb for anyone trying to figure out where all this ObjFW stuff
> came from.
>
> When I said a policy statement, I meant a more general expression of
> our policy towards this kind of thing. Off the top of my head, I would say:
>
> Clang's support for C++ and Objective-C is not intrinsically tied to any
> specific language implementation, such as a C++ ABI or Obj-C
> runtime. We believe that our parser, type-checker, and ASTs are
> reasonably well-factored to support a wide range of language
> implementations, and we welcome patches that add support for
> open, well-documented, and legally-unconstrained language
> implementations. We do ask that you only add support for projects
> that have reached a reasonable level of maturity. We may also
> later remove support for projects that have become unmaintained,
> or that impose maintenance burdens on clang out of proportion to
> their known user base.
>
> More informally, please don't send us patches to support college
> projects or personal toy implementations. :)
The "Contributing Extensions to Clang" section of http://clang.llvm.org/get_involved.html is meant to address this question; specifically, #1 and #3.
- Doug
More information about the cfe-commits
mailing list