Re: Commit messages and the move to git
On Mon, 4 Nov 2019 at 17:42, Joseph Myers wrote: > > On Mon, 4 Nov 2019, Segher Boessenkool wrote: > > > On Mon, Nov 04, 2019 at 04:19:25PM +, Jonathan Wakely wrote: > > > I've already proposed a more specific format for libstdc++: > > > https://gcc.gnu.org/ml/libstdc++/2019-09/msg00122.html > > > > PR libstdc++/12345 takes up the first 19 chars of the short subject, > > adding no useful information (unless the reader knows all PRs by heart, > > you need to look it up to know what it is). > > > > I usually put (PR12345) at the end of the subject. The area is clear > > from the rest of the subject already. > > Agreed. (Hint to patch submitters: if the subject line of your patch > submission is just "Fix PR12345" or similar, people are less likely to > review your patch because nothing about the subject tells anyone that the > patch is in their area and so something they should pay attention to. > Patch submissions need to have subjects that make clear very quickly what > the patch is about. This is also why I don't care for [PATCH] tags at the > start of subject lines - they take away space for saying what the patch is > about, and on gcc-patches we can expect things are patches, [PATCH] > doesn't add useful information.) I don't mind [PATCH] in the subject of patch emails (maybe because nearly all my patches go to libstdc++@ as well, and not all mails on that list are patches), but it has negative value in the commit log. My mail to the libstdc++ list should have noted that [PATCH] tags in the email subject should be omitted from the summary in the first line of the commit log. > I've been using git-style commit messages in GCC for the past five years. I think I only started four years ago :-)
Re: Commit messages and the move to git
On Tue, Nov 5, 2019 at 11:07 AM Jonathan Wakely wrote: > On Mon, 4 Nov 2019 at 17:42, Joseph Myers wrote: > > On Mon, 4 Nov 2019, Segher Boessenkool wrote: > > > > > On Mon, Nov 04, 2019 at 04:19:25PM +, Jonathan Wakely wrote: > > > > I've already proposed a more specific format for libstdc++: > > > > https://gcc.gnu.org/ml/libstdc++/2019-09/msg00122.html > > > > > > PR libstdc++/12345 takes up the first 19 chars of the short subject, > > > adding no useful information (unless the reader knows all PRs by heart, > > > you need to look it up to know what it is). > > > > > > I usually put (PR12345) at the end of the subject. The area is clear > > > from the rest of the subject already. > > > > Agreed. (Hint to patch submitters: if the subject line of your patch > > submission is just "Fix PR12345" or similar, people are less likely to > > review your patch because nothing about the subject tells anyone that the > > patch is in their area and so something they should pay attention to. > > Patch submissions need to have subjects that make clear very quickly what > > the patch is about. This is also why I don't care for [PATCH] tags at the > > start of subject lines - they take away space for saying what the patch is > > about, and on gcc-patches we can expect things are patches, [PATCH] > > doesn't add useful information.) > > I don't mind [PATCH] in the subject of patch emails (maybe because > nearly all my patches go to libstdc++@ as well, and not all mails on > that list are patches), but it has negative value in the commit log. I actively like [PATCH] in the subject line because I see patch mail interleaved with other mail in my inbox. > My mail to the libstdc++ list should have noted that [PATCH] tags in > the email subject should be omitted from the summary in the first line > of the commit log. And git format-patch/git am automatically add and remove [PATCH] appropriately. I tend to put the PR number at the beginning of the line, but I don't object to putting it at the end instead. Jason
GCC 7.5 Release Candidate available from gcc.gnu.org
The first release candidate for GCC 7.5 is available from
https://gcc.gnu.org/pub/gcc/snapshots/7.5.0-RC-20191105/
and shortly its mirrors. It has been generated from SVN revision 277823.
I have so far bootstrapped and tested the release candidate on
{x86_64,i586,ppc64le,s390x,aarch64}-linux. Please test it
and report any issues to bugzilla.
If all goes well, I'd like to release 7.5 on Thursday, November 14th.
Re: Commit messages and the move to git
On Tue, Nov 05, 2019 at 11:27:50AM +, Jason Merrill wrote: > On Tue, Nov 5, 2019 at 11:07 AM Jonathan Wakely wrote: > > On Mon, 4 Nov 2019 at 17:42, Joseph Myers wrote: > > > On Mon, 4 Nov 2019, Segher Boessenkool wrote: > > > > > > > On Mon, Nov 04, 2019 at 04:19:25PM +, Jonathan Wakely wrote: > > > > > I've already proposed a more specific format for libstdc++: > > > > > https://gcc.gnu.org/ml/libstdc++/2019-09/msg00122.html > > > > > > > > PR libstdc++/12345 takes up the first 19 chars of the short subject, > > > > adding no useful information (unless the reader knows all PRs by heart, > > > > you need to look it up to know what it is). > > > > > > > > I usually put (PR12345) at the end of the subject. The area is clear > > > > from the rest of the subject already. > > > > > > Agreed. (Hint to patch submitters: if the subject line of your patch > > > submission is just "Fix PR12345" or similar, people are less likely to > > > review your patch because nothing about the subject tells anyone that the > > > patch is in their area and so something they should pay attention to. > > > Patch submissions need to have subjects that make clear very quickly what > > > the patch is about. This is also why I don't care for [PATCH] tags at the > > > start of subject lines - they take away space for saying what the patch is > > > about, and on gcc-patches we can expect things are patches, [PATCH] > > > doesn't add useful information.) > > > > I don't mind [PATCH] in the subject of patch emails (maybe because > > nearly all my patches go to libstdc++@ as well, and not all mails on > > that list are patches), but it has negative value in the commit log. > > I actively like [PATCH] in the subject line because I see patch mail > interleaved with other mail in my inbox. > > > My mail to the libstdc++ list should have noted that [PATCH] tags in > > the email subject should be omitted from the summary in the first line > > of the commit log. > > And git format-patch/git am automatically add and remove [PATCH] > appropriately. Wrt [PATCH]: if we keep it, do we want to have a system to distinguish C/C++/... patches? Do we want [C++ PATCH] or [PATCH][C++] or [C++][PATCH], something else? (I find the latter two a bit ugly.) Marek
Re: Feedback request on how best to handle recursion in concept satisfaction
On Thu, Oct 31, 2019 at 8:03 AM Nathan Sidwell wrote:
> Why doesn't the std specify the satisfaction nesting limit in the same
> way as template instantiation? (at least that's what I infer from your
> question).
I'm not sure why it's not explicitly listed along with the template
instantiation limit ([implimits]/2.41). Perhaps it's something that
should be added? It does seem like a distinct limit since satisfaction
can occur recursively without having more than one template
instantiation in the call stack at any given time. To give an example:
template
requires requires(T t) { foo(t); }
void foo(T t) { }
A call to foo<1>(1) results in unbounded call stack like:
resolve foo<1>(int)
instantiate the decl of foo<1>(int)
check if foo<1>(int) satisfies its constraints
resolve foo<2>(int)
instantiate the decl of foo<2>(int)
check if foo<2>(int) satisfies its constraints
...
Per [temp.inst]/17 "the type-constraints and requires-clause of a
template specialization or member function are not instantiated along
with the specialization or function itself" so instantiating the decl
of foo<1>(int) does not depend on the instantiation of any other
template and the template instantiation depth is only incremented once
before decremented when control flow returns to overload resolution.
This needs to be resolved someway, but reusing the template
instantiation depth limit would be an odd choice since there are no
recursive template instantiations in the process. A parallel
-fsatisfaction-depth= limit and associated diagnostics seems like a
better way to resolve this issue.
Does this seem like a good way forward?
Thanks,
Re: Commit messages and the move to git
On Tue, 2019-11-05 at 11:27 +, Jason Merrill wrote: > On Tue, Nov 5, 2019 at 11:07 AM Jonathan Wakely < > jwakely@gmail.com> wrote: > > On Mon, 4 Nov 2019 at 17:42, Joseph Myers wrote: > > > On Mon, 4 Nov 2019, Segher Boessenkool wrote: > > > > > > > On Mon, Nov 04, 2019 at 04:19:25PM +, Jonathan Wakely > > > > wrote: > > > > > I've already proposed a more specific format for libstdc++: > > > > > https://gcc.gnu.org/ml/libstdc++/2019-09/msg00122.html > > > > > > > > PR libstdc++/12345 takes up the first 19 chars of the short > > > > subject, > > > > adding no useful information (unless the reader knows all PRs > > > > by heart, > > > > you need to look it up to know what it is). > > > > > > > > I usually put (PR12345) at the end of the subject. The area is > > > > clear > > > > from the rest of the subject already. > > > > > > Agreed. (Hint to patch submitters: if the subject line of your > > > patch > > > submission is just "Fix PR12345" or similar, people are less > > > likely to > > > review your patch because nothing about the subject tells anyone > > > that the > > > patch is in their area and so something they should pay attention > > > to. > > > Patch submissions need to have subjects that make clear very > > > quickly what > > > the patch is about. This is also why I don't care for [PATCH] > > > tags at the > > > start of subject lines - they take away space for saying what the > > > patch is > > > about, and on gcc-patches we can expect things are patches, > > > [PATCH] > > > doesn't add useful information.) > > > > I don't mind [PATCH] in the subject of patch emails (maybe because > > nearly all my patches go to libstdc++@ as well, and not all mails > > on > > that list are patches), but it has negative value in the commit > > log. > > I actively like [PATCH] in the subject line because I see patch mail > interleaved with other mail in my inbox. FWIW my convention has been to put "[PATCH]" in the email subject line for patches I want reviewed, and "[committed]" for patches that I've already self-approved (or are obvious) and thus don't need review. +1 from me on making commit messages have git-friendly summary lines (I've been doing this myself since shortly after I joined gcc). I'm not too bothered about the precise format FWIW - maybe it's better not to be too prescriptive about the format, beyond "make them concise, and useful for you and your fellow maintainers"? I try to use the same message as the email subject line, to make cross-referencing between the mailing list and source repos easier when doing "archaeology". (that said, keeping "[PATCH]" in the *commit* message is a pet peeve of mine, as it's redundant). I also tend to put in the "blurb" from the email into the commit message, especially if it's a pertinent high-level description of the purpose of the *change* (as opposed to a description of the *code*, which should live in a comment in the code, rather than the metadata). > > My mail to the libstdc++ list should have noted that [PATCH] tags > > in > > the email subject should be omitted from the summary in the first > > line > > of the commit log. > > And git format-patch/git am automatically add and remove [PATCH] > appropriately. > > I tend to put the PR number at the beginning of the line, but I don't > object to putting it at the end instead. > > Jason >
Re: Commit messages and the move to git
On 04/11/2019 16:04, Jeff Law wrote: > On 11/4/19 3:29 AM, Richard Earnshaw (lists) wrote: >> With the move to git fairly imminent now it would be nice if we could >> agree on a more git-friendly style of commit messages; and, ideally, >> start using them now so that the converted repository can benefit from >> this. > > I'd suggest we sync policy with glibc. They're further along on the > ChangeLog issues. Whatever they do in this space we should follow -- > aren't we going to be using some of their hooks/scripts? > > jeff > OK, based on these discussions here's an initial proposal for some wording in contribute.html for the web site. I've based it strongly on the libc version, mostly with some restructuring and a tweak around bug numbers. R. diff --git a/htdocs/contribute.html b/htdocs/contribute.html index 80ebb26f..8f5741e5 100644 --- a/htdocs/contribute.html +++ b/htdocs/contribute.html @@ -261,6 +261,89 @@ that ChangeLog entries may be included as part of the patch and diffs representing new files may be omitted, especially if large, since they can be accessed directly from the repository.) +Email subject lines + +Your contribution email subject line will become the first line of the +commit message for your patch. + +A high-quality email subject line for a contribution contains the +following elements: + + + A classifier + Component tags + An optional series identifier + A brief summary + An optional bug number + + +Classifier + +The classifier identifies the type of contribution, for example a +patch, an RFC (request for comments) or a committed patch (where +approval is not necessary. The classifier should be written in upper +case and surrounded with square brackets. This is the only component +of the email subject line that will not appear in the commit itself. +The classifier may optionally contain a version number (vN) and +a series marker (N/M). Examples are: + + + [PATCH] - a single patch + [PATCH v2] - the second version of a single patch + [PATCH 3/7] - the third patch in a series of seven +patches + [RFC] - a point of discussion, may contain a patch + [COMMITTED] - a patch that has already been committed. + + +Component tags + +A component tag is a short identifier that identifies the part of the +compiler being modified, this is important as it highlights to +relevant maintainers that the patch may need their attention. +Multiple components may be listed if necessary. Each component tag +should be followed by a colon. For example, + + + vax: testsuite: + libstdc++: + combine: + + +Series identifier + +The series identifier is optional and is only relevant if a number of +patches are needed in order to effect an overall change. It should be +a short string that identifies the series (it is common to all +patches) and should be followed by a single dash surrounded by white +space. + +Brief summary + +The brief summary encapsulates in a few words the intent of the +change. For example: cleanup check_field_decls. + +Bug number + +If your patch fixes a bug in the compiler for which there is an +existing PR number the bug number should be stated. Use the +short-form variant (PRn) without the bugzilla component +identifier. + +Other messages + +Some large patch sets benefit from an introductory email that provides +more context for the patch series and describes how the patches have +been broken up to provide for review. The convention is that such +messages should follow the same format as described above, but the +patch number should be set to zero, for example: [PATCH +0/7]. Remember that the introductory message will not be +committed with the patches themselves, so it should not contain any +important information that is not also covered in the individual +patches. If you send a summary email with a series it is a good idea +to send the patches as follow-ups (essentially replies) to your +initial message so that mail software can group the messages together. + Pinging patches, Getting patches applied If you do not receive a response to a patch that you have submitted
Re: Feedback request on how best to handle recursion in concept satisfaction
On Tue, Nov 5, 2019 at 2:42 PM Jeff Chapman wrote:
>
> On Thu, Oct 31, 2019 at 8:03 AM Nathan Sidwell wrote:
> > Why doesn't the std specify the satisfaction nesting limit in the same
> > way as template instantiation? (at least that's what I infer from your
> > question).
>
> I'm not sure why it's not explicitly listed along with the template
> instantiation limit ([implimits]/2.41). Perhaps it's something that
> should be added? It does seem like a distinct limit since satisfaction
> can occur recursively without having more than one template
> instantiation in the call stack at any given time. To give an example:
>
> template
> requires requires(T t) { foo(t); }
> void foo(T t) { }
>
> A call to foo<1>(1) results in unbounded call stack like:
>
> resolve foo<1>(int)
> instantiate the decl of foo<1>(int)
> check if foo<1>(int) satisfies its constraints
> resolve foo<2>(int)
> instantiate the decl of foo<2>(int)
> check if foo<2>(int) satisfies its constraints
> ...
>
> Per [temp.inst]/17 "the type-constraints and requires-clause of a
> template specialization or member function are not instantiated along
> with the specialization or function itself" so instantiating the decl
> of foo<1>(int) does not depend on the instantiation of any other
> template and the template instantiation depth is only incremented once
> before decremented when control flow returns to overload resolution.
>
> This needs to be resolved someway, but reusing the template
> instantiation depth limit would be an odd choice since there are no
> recursive template instantiations in the process. A parallel
> -fsatisfaction-depth= limit and associated diagnostics seems like a
> better way to resolve this issue.
We track other substitution cases as part of the template
instantiation depth limit, notably instantiating the
noexcept-specifier. This seems like a similar situation.
Jason
Re: GCC 7.5 Release Candidate available from gcc.gnu.org
On 11/5/19 6:45 AM, Richard Biener wrote:
The first release candidate for GCC 7.5 is available from
https://gcc.gnu.org/pub/gcc/snapshots/7.5.0-RC-20191105/
and shortly its mirrors. It has been generated from SVN revision 277823.
I have so far bootstrapped and tested the release candidate on
{x86_64,i586,ppc64le,s390x,aarch64}-linux. Please test it
and report any issues to bugzilla.
If all goes well, I'd like to release 7.5 on Thursday, November 14th.
I bootstrapped this on BE powerpc64 on power 7 and 8 and on LE powerpc64
on power 8 and 9 and nothing untoward was seen.
--
-Bill Seurer
Re: Commit messages and the move to git
On Tue, Nov 05, 2019 at 11:07:05AM +, Jonathan Wakely wrote: > On Mon, 4 Nov 2019 at 17:42, Joseph Myers wrote: > > I've been using git-style commit messages in GCC for the past five years. > > I think I only started four years ago :-) I amr210190 Wed May 7 22:00:58 2014 + Joseph is r214526 Tue Aug 26 17:06:31 2014 + You are r218698 Sat Dec 13 20:44:06 2014 + Anyone else playing? ;-) Segher
Re: Commit messages and the move to git
Segher Boessenkool wrote: > On Tue, Nov 05, 2019 at 11:07:05AM +, Jonathan Wakely wrote: >> On Mon, 4 Nov 2019 at 17:42, Joseph Myers wrote: >>> I've been using git-style commit messages in GCC for the past five years. >> >> I think I only started four years ago :-) > > I amr210190 Wed May 7 22:00:58 2014 + > Joseph is r214526 Tue Aug 26 17:06:31 2014 + > You are r218698 Sat Dec 13 20:44:06 2014 + > > Anyone else playing? ;-) I am - but probably for much less time than the others … I think I started around the time Joseph observed it would be a good idea to make the eventual commit messages nicer. Iain > > > Segher
Re: Commit messages and the move to git
On 05/11/2019 14:12, Marek Polacek wrote: > On Tue, Nov 05, 2019 at 11:27:50AM +, Jason Merrill wrote: >> On Tue, Nov 5, 2019 at 11:07 AM Jonathan Wakely >> wrote: >>> On Mon, 4 Nov 2019 at 17:42, Joseph Myers wrote: On Mon, 4 Nov 2019, Segher Boessenkool wrote: > On Mon, Nov 04, 2019 at 04:19:25PM +, Jonathan Wakely wrote: >> I've already proposed a more specific format for libstdc++: >> https://gcc.gnu.org/ml/libstdc++/2019-09/msg00122.html > > PR libstdc++/12345 takes up the first 19 chars of the short subject, > adding no useful information (unless the reader knows all PRs by heart, > you need to look it up to know what it is). > > I usually put (PR12345) at the end of the subject. The area is clear > from the rest of the subject already. Agreed. (Hint to patch submitters: if the subject line of your patch submission is just "Fix PR12345" or similar, people are less likely to review your patch because nothing about the subject tells anyone that the patch is in their area and so something they should pay attention to. Patch submissions need to have subjects that make clear very quickly what the patch is about. This is also why I don't care for [PATCH] tags at the start of subject lines - they take away space for saying what the patch is about, and on gcc-patches we can expect things are patches, [PATCH] doesn't add useful information.) >>> >>> I don't mind [PATCH] in the subject of patch emails (maybe because >>> nearly all my patches go to libstdc++@ as well, and not all mails on >>> that list are patches), but it has negative value in the commit log. >> >> I actively like [PATCH] in the subject line because I see patch mail >> interleaved with other mail in my inbox. >> >>> My mail to the libstdc++ list should have noted that [PATCH] tags in >>> the email subject should be omitted from the summary in the first line >>> of the commit log. >> >> And git format-patch/git am automatically add and remove [PATCH] >> appropriately. > > Wrt [PATCH]: if we keep it, do we want to have a system to distinguish > C/C++/... patches? Do we want [C++ PATCH] or [PATCH][C++] or [C++][PATCH], > something else? (I find the latter two a bit ugly.) > "git am --keep-non-patch" will strip sequences containing [.*PATCH.*] (not a strict regexp, .* is anything other than ']'), and keep other [.*] annotations. I don't know if this applies only up to the first non-matching sequence, or at any point. See git-mailinfo's -b flag. But my proposal (see post earlier) is that we should use : in the same way that libc (and, I understand, linux kernel folk) do. R. > Marek >
Re: Commit messages and the move to git
On 05/11/2019 02:51, Kewen.Lin wrote: > Hi, > > on 2019/11/4 下午6:29, Richard Earnshaw (lists) wrote: >> With the move to git fairly imminent now it would be nice if we could agree >> on a more git-friendly style of commit messages; and, ideally, start using >> them now so that the converted repository can benefit from this. >> >> Some tools, particularly gitk or git log --oneline, can use one-line >> summaries from a commit's log message when listing commits. It would be >> nice if we could start adopting a style that is compatible with this, so >> that in future commits are summarized in a useful way. Unfortunately, some >> of our existing commits show no useful information with tools like this. >> >> Eg. >> >> git log --oneline >> 2b70dbd64b5 (HEAD -> master, origin/trunk, origin/master, origin/HEAD) >> 2019-11-01 Kewen Lin >> 29f4f5f13b9 [C++ PATCH] cleanup check_field_decls >> 0f931fb75ae 2019-11-01 Kewen Lin >> e9c4da22199 OpenMP] use_device_addr/use_device_ptr with Fortran >> allocatable/pointer arrays >> 377311a90fa 2019-11-01 Kewen Lin > > Sorry for the awful commit messages and thanks a lot for raising this up to > stop me from stumbling continuously. > > I just updated all my svn commit comments by "svn propedit svn:log --revprop > -r N --editor-cmd vim", > but I guess it won't help any more if the upcoming git repo will come from > some existing mirror? > > > BR, > Kewen > Sorry, I wasn't intending to victimise you. It just so happened that you had several commits at the head of my tree when I used the command. I'm not sure it's worth rewriting history. We've so many historically non-compliant commits that they'll never be fixed up. But we can amend our ways for the future. R.
Re: Commit messages and the move to git
Hi! On Tue, Nov 05, 2019 at 09:50:37AM -0500, David Malcolm wrote: > FWIW my convention has been to put "[PATCH]" in the email subject line > for patches I want reviewed, and "[committed]" for patches that I've > already self-approved (or are obvious) and thus don't need review. And there is [RFC] as well. As already noted, the advantage of [PATCH] is that many tools know how to handle that, already, so it may fit into your workflow better (git am removes *all* leading bracketed strings, by default). Also making a mail that can just be applied with git-am is useful if you want other people to be able to commit your patches. We usually commit our own patches, but this is still important for people who want to test out a patch, etc. I recommend preparing your patches with git format-patch: it takes care of all details for you. You still should follow some rules, like using scissors lines, and maximum line length 72, etc., but it makes mails that follow all our rules for mime encoding and the like. > I'm not too bothered about the precise format FWIW - maybe it's better > not to be too prescriptive about the format, beyond "make them concise, > and useful for you and your fellow maintainers"? +2 If we want to standardise on other things, like have subjects like for example "combine: Frob the fubar" (and what those tags should be exactly) that will work itself out hopefully. As long as subjects are nice and useful, everyone should be happy. > I try to use the > same message as the email subject line, to make cross-referencing > between the mailing list and source repos easier when doing > "archaeology". I use the whole email as commit message. This works quite well imo, and it's the "standard" way of using git. This also works nicely with patchwork, if anyone but me uses that still :-) > I also tend to put in the "blurb" from the email into the commit > message, especially if it's a pertinent high-level description of the > purpose of the *change* (as opposed to a description of the *code*, > which should live in a comment in the code, rather than the metadata). Purpose and mechanics and whatnot, yeah -- but of the change, indeed: it should be text relevant to people who want to know what changed (and why). Anything you would put in the mail thread that people looking at the committed patches would still like to see. > > I tend to put the PR number at the beginning of the line, but I don't > > object to putting it at the end instead. I don't think we need to standardise this, certainly not before we have enough experience with this. Everyone works differently, we should just figure out a way we can work together best. A PR # at the start of the subject can be useful, if it leaves enough space for other important info. Segher
I am interested in posting on your blog…https://gcc.gnu.org/
Hi! > I am interested in posting on your blog… https://gcc.gnu.org/ > need to know some things in advance before I include your site in my > offer:1. Final and flat best rates per post. > 2. Type of links (dofollow). > 3. Do you accept easy writing article > 4. Donot add disclosures/sponsored tags. > Payments are sorted in 7+ business days after posting via Paypal > unless else is preagreed. > If you run other sites in any niche and language feel free to share > with the above info. > Hope you can understand. > Looking forward to working with you! > Cheers!
