On Jul 12, 2012, at 12:42 AM, John McCall <[email protected]> wrote:
> 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. :) 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 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
