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

[John McCall]

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. :)

John.