From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 9D0D1385828B for ; Wed, 10 Aug 2022 19:06:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9D0D1385828B Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-339-z1Wz9Y0ONeODPlIwN4XQYg-1; Wed, 10 Aug 2022 15:06:53 -0400 X-MC-Unique: z1Wz9Y0ONeODPlIwN4XQYg-1 Received: by mail-qk1-f200.google.com with SMTP id u15-20020a05620a0c4f00b006b8b3f41303so13118743qki.8 for ; Wed, 10 Aug 2022 12:06:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc; bh=IQ0FrN5ASighEfPivMbUywSouUNxsebpEFhnSTZbNd0=; b=fz4KI85KIodlM4zwo38FeVAYi+dqPzdTk/AR3HzU2YcshfaOhOnqbVf2DFoNu3ePNC XftrBWZ/ezwG3ODcgB7T6eGUE4ku8jJja/lx59lW6jwXf7rUvhiQ39xEOxtvrRe656XA 8X1pJO1zO0UZJomHIqkATMD1UmEnyTO9x1OwtvwbIZWXu9Kt/S8g/KRMU9U91rm7gwAT p/eBRpN6gv4XUCbigA+TaHpL1o+cA5b7FPlPSfv+nElePgdgU7amdRuSI6RMYUf/4wLm 5n/TBg2Bku0AFMikH6X6zfD6vfhAoc/dw+bnWoOrbyjnoJmXTRvqdzTF0iqSdRsGcva9 49Aw== X-Gm-Message-State: ACgBeo3oqdFrjGJizp3WVehpacUMsQu4cga5yLD9aXEDV6XVCpqIaEQt pvT4CeQf9kpXGMblZVgZGsFvCSV8YZqrzOU0XVutHo/o3UMitG4iaZiZWmCQkRnwADnFjlaHyqa +orMGYqQeAujvYzbPBQ== X-Received: by 2002:a05:620a:2411:b0:6b9:95c5:5f76 with SMTP id d17-20020a05620a241100b006b995c55f76mr4817840qkn.509.1660158412068; Wed, 10 Aug 2022 12:06:52 -0700 (PDT) X-Google-Smtp-Source: AA6agR5XQ2VlWGb43QCDu2HGMOijKQ8w/v6vZ4GAzIUIFyf9VJknTOgprCgGYJ04tSItfgRU8O9vdw== X-Received: by 2002:a05:620a:2411:b0:6b9:95c5:5f76 with SMTP id d17-20020a05620a241100b006b995c55f76mr4817822qkn.509.1660158411774; Wed, 10 Aug 2022 12:06:51 -0700 (PDT) Received: from t14s.localdomain (c-73-69-212-193.hsd1.nh.comcast.net. [73.69.212.193]) by smtp.gmail.com with ESMTPSA id cj20-20020a05622a259400b00339b8a5639csm303231qtb.95.2022.08.10.12.06.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Aug 2022 12:06:51 -0700 (PDT) Message-ID: <7a069325c7db98d626cb589d260a62af16232ace.camel@redhat.com> Subject: Re: Rust frontend patches v1 From: David Malcolm To: Philip Herron , gcc-patches@gcc.gnu.org Cc: manu@gcc.gnu.org Date: Wed, 10 Aug 2022 15:06:50 -0400 In-Reply-To: References: <20220727134040.843750-1-philip.herron@embecosm.com> <52031efabcd85759ff3bf3a4d0c6a4ff0b47128e.camel@redhat.com> User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_NUMSUBJECT, KAM_SHORT, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2022 19:06:56 -0000 On Wed, 2022-08-10 at 19:56 +0100, Philip Herron wrote: > Hi everyone > > For my v2 of the patches, I've been spending a lot of time ensuring > each patch is buildable. It would end up being simpler if it was > possible if each patch did not have to be like this so I could split > up the front-end in more patches. Does this make sense? Yes. I've often split up patches into chunks when posting them for review, and I see other people here do that. It makes it easier for the reviewer also, since it's usually easier to deal with e.g. 10 small patches than one enormous one (e.g. if many of them are uncontroversial, having them split up makes it easier to focus attention on just the controversial areas). > In theory, > when everything goes well, does this still mean that we can merge in > one commit,  Split up the patches for review, but make a note in the cover letter than they would all be merged into one when committing. (especially if doing the split is taking up a lot of time; we don't want to be mandating busy-work) Dave > or should it follow a series of buildable patches? I've > received feedback that it might be possible to ignore making each > patch an independent chunk and just focus on splitting it up as small > as possible even if they don't build. > > I hope this makes sense. > > Thanks > > --Phil > > On Thu, 28 Jul 2022 at 10:39, Philip Herron < > philip.herron@embecosm.com> wrote: > > > > Thanks, for confirming David. I think it was too big in the end. I > > was > > trying to figure out how to actually split that up but it seems > > reasonable that I can split up the front-end patches into patches > > for > > each separate pass in the compiler seems like a reasonable approach > > for now. > > > > --Phil > > > > On Wed, 27 Jul 2022 at 17:45, David Malcolm > > wrote: > > > > > > On Wed, 2022-07-27 at 14:40 +0100, herron.philip--- via Gcc- > > > patches > > > wrote: > > > > This is the initial version 1 patch set for the Rust front-end. > > > > There > > > > are more changes that need to be extracted out for all the > > > > target > > > > hooks we have implemented. The goal is to see if we are > > > > implementing > > > > the target hooks information for x86 and arm. We have more > > > > patches > > > > for the other targets I can add in here but they all follow the > > > > pattern established here. > > > > > > > > Each patch is buildable on its own and rebased ontop of > > > > 718cf8d0bd32689192200d2156722167fd21a647. As for ensuring we > > > > keep > > > > attribution for all the patches we have received in the front- > > > > end > > > > should we create a CONTRIBUTOR's file inside the front-end > > > > folder? > > > > > > > > Note thanks to Thomas Schwinge and Mark Wielaard, we are > > > > keeping a > > > > branch up to date with our code on: > > > > > > > > https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/devel/rust/master > > > >  but this is not rebased ontop of gcc head. > > > > > > > > Let me know if I have sent these patches correctly or not, this > > > > is a > > > > learning experience with git send-email. > > > > > > > > [PATCH Rust front-end v1 1/4] Add skeleton Rust front-end > > > > folder > > > > [PATCH Rust front-end v1 2/4] Add Rust lang TargetHooks for > > > > i386 and > > > > [PATCH Rust front-end v1 3/4] Add Rust target hooks to ARM > > > > [PATCH Rust front-end v1 4/4] Add Rust front-end and associated > > > > > > FWIW it looks like patch 4 of the kit didn't make it (I didn't > > > get a > > > copy and I don't see it in the archives). > > > > > > Maybe it exceeded a size limit?  If so, maybe try splitting it up > > > into > > > more patches. > > > > > > Dave > > > >