[cfe-commits] [PATCH] Add -fobjc-direct-class-refs

[Douglas Gregor]

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