On Mon, 2022-07-18 at 20:35 +0100, lkcl via Gcc wrote: > (apologies top-posting, strange mobile mailer). i would expect in that > case that the Rust Foundation to work closely with Certification Mark > Licensees, and to come to an accommodation, defining a subset if > necessary. > > if the gcc developers can clearly enunciate why shipping a "borrow > checker" (whatever that is) is unreasonable, the Certification Mark > Holder has to take that into consideration. without knowing full > details i would expect it to be a third party library of some kind > (rather than libgcc.a) > > Certification Mark Holders *have* to act FRAND otherwise they lose the > Certification Mark > > aside: it is reasonable for a Certification Mark Holder to require full > compliance, they are after all the Custodians of the Language, and one > would not expect a broken (non-compliant) compiler to actually be > distributed, regardless of a Certification Mark. > > thus i think you'll find that the usual "pre-alpha alpha beta" release > cycles which would and would not naturally be released for distribution > fit directly and one-to-one with what a Certification Mark Holder would > and would not authorise. > > regarding missing tests: well, tough titty on the Certification Mark > Holder. if they cannot define the Compliance Test Suite they cannot > tell people they are non-compliant, can they! > > thus although quirky it all works out. > > (whereas telling people what patches they can and cannot apply just > pisses them off).
I've been trying to ignore this thread, but unfortunately it seems to still be going on. Luke: you appear to me to be the one who is telling people what patches they can and cannot apply, and it's pissing me off. You seem to me to be constructing elaborate arguments for why there's some kind of legal problem here, and elaborate purported workarounds, when it isn't at all clear to me that there are any problems. Are you a lawyer? If so please consider volunteering your time to the GCC Steering Committee *privately*. If not, it seems to me to be a terrible idea to try to get the developers to pontificate in public about alleged legal issues with the project, their implications, and supposed workarounds. The GCC Steering Committee has approved merging the rust frontend into GCC. It's a big project, so I fully expect that the frontend that we ship in GCC 13.1 will have bugs, missing functionality, and slight differences compared to rustc. I'm guessing we'll need to have some kind of in the release notes for GCC 13 to set people's expectations - perhaps the GCC 13 release of the rust frontend will be considered just of "alpha" quality, for people to "kick the tyres" - but I leave that judgement call to Philip and the other gcc rust developers. There are no doubt "unknown unknowns" (to misquote Donald Rumsfeld), and shaking these out will make help both the GCC and Rust communities - but please can we leave the technical issues to the developers doing the work (I'm a gcc developer, but merely a rust "fanboy"). The gcc rust frontend is an ambitious one with lots of technical challenges, but which has the potential to make the GCC and Rust development communities stronger; this discussion seems to me to be a pointless attempt to pick a fight between the two. These opinions are my own, and not those of my employer, etc etc Dave > > l. > > > > On July 18, 2022 7:32:25 PM GMT+01:00, Florian Weimer < > fwei...@redhat.com> wrote: > > * lkcl via Gcc: > > > > > if the Rust Foundation were to add an extremely simple phrase > > > > > > "to be able to use the word rust in a distributed compiler your > > > modifications must 100% pass the test suite without modifying > > > the test suite" > > > > > > then all the problems and pain goes away. > > > > No. It would actually make matters worse for GCC in this case > > because > > the stated intent is to ship without a borrow checker (“There are no > > immediate plans for a borrow checker as this is not required to > > compile > > rust code”, <https://rust-gcc.github.io/>, retrieved 2022-07-18). > > There > > are of course tests for the borrow checker in the Rust test suite, > > and > > those that check for expected compiler errors will fail with GCC. > > > > Thanks, > > Florian >
