On Jul 11, 2012, at 11:46 PM, David Blaikie wrote: > On Wed, Jul 11, 2012 at 11:36 PM, John McCall <[email protected]> wrote: >> On Jul 11, 2012, at 10:17 PM, David Blaikie wrote: >>> On Wed, Jul 11, 2012 at 7:32 PM, Jonathan Schleifer <[email protected]> >>> 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. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
