, so if we want to
change looping-const-or-pure to something like const-or-pure-with-side-effects
we should constrain things more.
That would be fine with me.
Jason
ction, which is not inline.
Jason
s' as discussed here.
I think we can leave the wrapper as a normal inline and use the same
attribute on the init function; it also has the property of only having
side-effects on the first call, it just doesn't return anything.
Jason
init) i_init();
return i;
}
and your suggestion would change it to
int& i_wrap()
{
if (i_init && !i_initialized) { i_initialized = true; i_init(); }
return i;
}
In previous discussions, people thought this would be less efficient.
Jason
re or less efficient.
or this:
[EXTERN] __thread T *i;
Same answer. If we aren't trying to maintain compatibility, this
approach seems like it would be more efficient than i_initialize.
Jason
On 07/03/2012 03:18 PM, Jason Merrill wrote:
2) Object layout changes to std::list and std::basic_string. For these
types, there is no way to both retain backward compatibility with older
C++98 code and conform to the C++11 standard. The best we can hope for
is to allow old code to coexist
On 01/22/2013 01:01 AM, Mayuresh Kathe wrote:
Hello, may I know the estimated timeframe by which full support for
C++11 would be added in to GCC?
GCC 4.8 will be feature-complete except for ref-qualifiers, which should
go onto the trunk soon, and perhaps into a later 4.8.x release.
Jason
27;t
propagate.
Jason
warn if a type is missing a tag that one of its subtypes has.
Jason
On 01/23/2013 01:48 AM, Franz Fehringer wrote:
What does this mean for the Concurrency section, it has 8xNo at the moment?
I need to go back over that section, but I think it's just inaccurate.
Jason
On 01/28/2013 02:24 PM, Jason Merrill wrote:
On 01/23/2013 01:48 AM, Franz Fehringer wrote:
What does this mean for the Concurrency section, it has 8xNo at the
moment?
I need to go back over that section, but I think it's just inaccurate.
I've now updated the page.
Jason
On 02/16/2013 01:30 AM, Franz Fehringer wrote:
Will gcc 4.8 contain the stdatomic.h header (i am a little confused
about it, is it a standard header?)?
It's part of the C11 standard, not C++11. C11 atomics will not be
supported in 4.8, but should be in 4.9.
Jason
hey can
specify the flag appropriately.
Jason
those who wish
to keep old behaviour, etc would be helpful.
Absolutely.
Jason
On 03/05/2013 02:28 PM, Lawrence Crowl wrote:
Are you planning for C++11 ABI stability in 4.9?
Yes. But if mangling bugs are discovered after 4.9, I propose to just
fix them (as I believe EDG and Clang do) rather than hold them in
reserve as we have been doing.
Jason
some of them could be ordinary
warnings when not -pedantic, and pedwarns when -pedantic.
Sounds like we want a separate category of diagnostic with the current
C++ pedwarn semantics so that we can change pedwarns themselves back to
a warning by default.
Jason
> > Anyone familiar with the idea of trying to describe a machine the way
> > it works?
> > like where it's being a machine working the way of having a loop with
> > the problem of being in
> > the middle and then to the outside as how the machine can move? so
> > like if you were to make it a mach
> Anyone familiar with the idea of trying to describe a machine the way
> it works?
> like where it's being a machine working the way of having a loop with
> the problem of being in
> the middle and then to the outside as how the machine can move? so
> like if you were to make it a machine
> that d
- Moving pairs
Given something like a checkers board, moving pairs would be checkers
paired together and arranged on the board
Given something like a checkers board, moving pairs are checker pieces
said to be paired.
The pairs don't have to be next to eachother.
Any way arranged is fair for how
- Moving pairs
Given something like a checkers board, moving pairs would be checker pieces
paired together and arranged on the board so they each checker piece
is said to be paired with another.
The pairs don't have to be next to eachother, they can arrange on the
board in any awy.
Any way arran
Say pieces on a board, make each a pair with another piece.
like...
|55|44|66|
|44|66|55|
so figure out how a piece can move.
pick any piece, try to move it somewhere.
when you move a piece you have to move it's pair at the same time.
when you move to a piece it's pair has to move at the same t
can't a machine always be seen where every part of the machine is one
way, for another part to be one way?
i mean... say you can take a bunch of parts and have it so each part
has only one way to be.
then parts can be together, where they fit the way that each part can
only be one way for the way
Say pieces on a board, make each piece a pair with another piece.
like...
|55|33|66|
|44|66|55|
|33|44|22|
|22|11|11|
a piece can only be figured out to move one way...
pick any piece, try to move it somewhere...
have the chosen piece move to another piece, it moves there and makes
the other
Paolo Bonzini wrote:
http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01305.html
dwarf2out.c (CCing Jason Merrill)
That patch went in a while back, but your message led me to the one that
still needed reviewing. :)
Jason
ing, and
any signed/unsigned type can alias the other signage.
Jason
Joe Buck wrote:
On Tue, Sep 23, 2008 at 05:51:23PM -0400, Jason Merrill wrote:
Mark Mitchell wrote:
Is that desirable? Type-based alias analysis should be able to take
advantage of the difference between them; a "char **" and a "signed char
**" cannot point at the sam
Mark Mitchell wrote:
PR 30252: Wrong code generation, perhaps due to the C++ front end's
representation for base classes. Jason, are you actively investigating
this one?
I haven't been; I've been working on the forced unwind stuff, and
looking at the rvalue refs patch. If
the bug, or apply Richard Guenther's
other patch to work around it?
Jason
s releases is better because it's not a regression.
Jason
t that reverting the change is a
conservative move, likely to lead to less optimal code, but not wrong
code. Are you? (That's a serious question; not a rhetorical one.)
That's a fair question; I don't know anything about the patch or the bug
it was intended to fix. Richard would know better.
Jason
inner
block?
Yes.
Jason
v3\libsupc++\guard.cc uses the class __guard from
libstdc++-v3\include\ext\concurrence.h which depends on the symbol
__GTHREAD_HAS_COND and is undefined now.
Hmm? __guard is a typedef in cxxabi-tweaks.h and doesn't depend on
__GTHREAD_HAS_COND.
Jason
would be to leave the calls to gimplify_stmt
(or probably change them to gimplify_to_stmt_list) and return
GS_ALL_DONE from cp_gimplify_expr.
Jason
y
be considered for release timing.
Incidentally, how are priorities assigned to bugs? I don't see any
guidelines on the website.
Jason
David Miller wrote:
But wouldn't you agree that it's not all that great to ship a new
feature in GCC that users have already found ways to ICE?
Oh, absolutely, it's just not a regression.
Jason
skaller wrote:
But Jason, the compiler worked properly in rejecting invalid syntax.
Now you're suggesting it fails to do so. This suggests a real regression
and a real bug: the new feature should have an enabling flag
that couldn't have been set before it was implemented, and without
only thing you consider
when deciding whether or not to make a release?
I agree that PR32252 (the example given by Jason) should not be P1.
I've downgraded it to P2. (P2 means "regression users will notice on a
major platform, but not P1". P3 means "not yet looked at&qu
ll
be at least a 4.2.3 before 4.3.0 goes out.
Distributors are interested in a timely 4.3.0 because they'll be using
whatever compiler they settle on for a long time and would like it to be
up to date. Sometimes some of the new features are important to support
the needs of other parts of the system.
Jason
ect should be the same except that
people don't have to deal with checking patches in on the branch vs. the
trunk until after 4.3.0 goes out.
Jason
Benjamin Kosnik wrote:
Jason, any thoughts on how to translate "ready to make a .0 release"
into "made a .0 release," in terms of a firm schedule, with dates? I'm
assuming that the < 100 bugzilla count is an adequate milestone for the
release branch to be cut.
O
just a draft.
It was voted into the C++ standard working paper at the last meeting.
And the C committee has expressed interest in adopting it, or something
similar, as well.
Jason
ip cv-quals, and
we don't want that to discard important attributes.
One solution to this issue would be to simply disallow attributes on
structs after the definition. Failing that, we need to define how they
interact with the type system. Opinions?
Jason
YPE_MAIN_VARIANT
without copying the fields, which is why things break.
A simple solution might be to just have
build_type_attribute_qual_variant refuse to make a variant of
record/enum types. This will reject the may_alias cases that break, but
leave existing use of aligned/packed/unused/deprecated alone.
Jason
ent variant that they're
crazy and need to write another union.
Note that when I fix build_duplicate_type to work properly, the C++
compiler rejects the first usage because U doesn't refer to the original
type, so it isn't used for linkage. Perhaps that's why
build_duplicate_type got broken.
Jason
Jason Merrill wrote:
Note that when I fix build_duplicate_type to work properly, the C++
compiler rejects the first usage because U doesn't refer to the original
type, so it isn't used for linkage.
...if you try to use U as an argument type to a function with C++ linkage.
Jason
Jason Merrill wrote:
Note that when I fix build_duplicate_type to work properly, the C++
compiler rejects the first usage because U doesn't refer to the original
type, so it isn't used for linkage. Perhaps that's why
build_duplicate_type got broken.
Actually, this happens re
where the UltraSparc3 extensions are used.
Does anybody have any idea why this might happen? Is this expected
behaviour for the UltraSparc3 as opposed to the UltraSparc3cu?
Thanks
Jason
rch=ultrasparc3'. Unless I'm missing something.
Jason
d, 0x44, 0x72, 0x61, 0x66, 0x74, 0x73, 0x20,
...
I wish that instead of (u8[]) I could write (u8[] __stuffdata), but
this doesn't work. As a consequence, the data winds up in the wrong
section.
Is this a gcc limitation, or is there some wild syntax that would make
this possible?
Thanks,
Jason
ssuming this is an array of a huge amount of
chacha20poly1305_testvec, I'm not sure if there's a syntax for me to
define the symbol inline with the declarations. Any ideas?
Regards,
Jason
per
https://git.zx2c4.com/WireGuard/commit/?id=f4698d20f13946afc6ce99e98685ba3f9adc4474
Jason
problem. Presumably this is due to
some instructions used in cortex-a15 mode that assume little endian
data, when -mbe8 requires otherwise.
Thanks,
Jason
$ armeb-pc-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=armeb-pc-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/armeb-pc-linux-gn
very
curious if somebody knows which heuristic gcc is applying here, and
why exactly. It's not something done by any other compiler I could
find, and it only started happening with gcc 6.
Regards,
Jason
foo
has been made into an ordinary symbol:
'
$ cat t.c
static inline __attribute__((always_inline))
void foo(void) {}
static
void (&bar)(void) = foo;
void f(void){ bar();}
$ g++ -std=gnu++11 -x c++ -Wall -Wextra -c t.c
$
'
I think g++ should have warned that it is not treating
an always inline function as inline here !
This problem is causing me grief in more real-world scenarios -
any advice on how to create an alias that is inline-able in C++
would be much appreciated.
Thanks & Best Regards,
Jason
On 01/04/2018, Max Filippov wrote:
> On Sun, Apr 1, 2018 at 4:34 AM, Jason Vas Dias
> wrote:
>> In C++ however, it does not compile :
>>
>> $ g++ -g -std=gnu++11 -x c++ -c t.c
>> t.c:5:8: error: 'void bar()' aliased to undefined symbol 'foo'
&g
ction of '1'
from it, and store sign-extended low 16 bits in 'a' - this is NOT
what is going on here ) .
I'd like to remove either '-pedantic' or '-Wconversion' from the
warning flags, but this is not an option .
Please can GCC fix this warning bug eventually - I have to wade
through code that generates thousands of them per compilation.
Thanks & Best Regards,
Jason
not using libasan for my project, just trying to build
latest GCC 6.4.1 with latest retpoline backports & bugfixes
into a version that passes its test suite, and I noticed this
problem - this is the main 'unexpected failure' source .
I guess I should class this an 'unexpected but don't care' failure ?
I just thought I should let the GCC developers know .
Thanks & Best Regards,
Jason
'
wice.
It looks like libasan still needs some major re-working
and I question why it is being included in the standard GCC
distribution & whether its test suite has ever passed.
Best Regards,
Jason
basan build
does build all the libasan.a objects without -fPIC -DPIC
correctly, and so does not have this problem.
It looks like use of 'static-libasan' in GCC 6 builds
is thoroughly disabled and broken because of libasan.a
objects ARE built with -fPIC / -DPIC .
Maybe I should raise a bug about this?
Thanks & Regards,
Jason
lation
documentation (it does not appear to be) ? Any plans to enable it in
near future ?
Thanks in advance for any replies,
Jason Vas Dias
#include
#include
struct state
{
unsigned char
bit1:1 , bit2:1 , bit3:1 , bit4:1
, bit5:1 , bit6:1
OK in my book for gcc
to finish compilation and linkage with no errors or warnings, when
it has encountered a __thread usage that it must know will have no
effect.
And isn't there an easier way to determine if TLS is enabled or not
than by compiling a test program ?
Thanks & Regards,
Jason
/*
*
* The output of this with gcc 4.7.2 is:
*
* 1
* 2
* this generic-int function should not be called
* 0
*
*
*
* The output of this with gcc 4.6.3 is:
*
* 1
* 2
* this type-bool function SHOULD BE called
* 1
*
*/
#include
#include
#include
#include
struct Type { int dummy
Was there a decision somewhere to require ChangeLog entries for all
testcase changes now, as the hook is enforcing? They were optional before.
remote: *** ChangeLog format failed:
remote: ERR: changed file not mentioned in a
ChangeLog:"gcc/testsuite/g++.dg/parse/error33.C"
On Thu, May 21, 2020 a
On Thu, May 21, 2020 at 2:58 PM Martin Liška wrote:
> On 5/21/20 8:52 PM, Jason Merrill wrote:
> > Was there a decision somewhere to require ChangeLog entries for all
> testcase changes now, as the hook is enforcing? They were optional before.
>
> Right now we ignore new
On Thu, May 21, 2020 at 4:27 PM Martin Liška wrote:
> On 5/21/20 9:51 PM, Jason Merrill wrote:
> > Modified. Adjustments to expected errors in testcases don't seem to me
> worth documenting in a ChangeLog.
>
> I see. As Jakub mentioned, I would keep the hook stricter fo
it -a --amend -e -F
> changelog
With these git aliases:
mklog-editor = "!f() { git show | git gcc-mklog >> $1; }; f"
addlog = "!f() { GIT_EDITOR='git mklog-editor' git commit --amend; }; f"
I can 'git addlog' to append the output of mklog to the current
commit. Probably better would be to do something with
prepare-commit-msg.
Jason
On Thu, May 21, 2020 at 6:03 PM Jason Merrill wrote:
>
> On Fri, May 15, 2020 at 11:39 AM Martin Liška wrote:
> >
> > On 5/15/20 3:22 PM, Marek Polacek wrote:
> > > On Fri, May 15, 2020 at 03:12:27PM +0200, Martin Liška wrote:
> > >> On 5/15/20 2:42 PM,
On Mon, May 25, 2020 at 5:23 AM Martin Liška wrote:
>
> On 5/22/20 11:01 PM, Jason Merrill wrote:
> > On Thu, May 21, 2020 at 6:03 PM Jason Merrill wrote:
> >>
> >> On Fri, May 15, 2020 at 11:39 AM Martin Liška wrote:
> >>>
> >>> On 5/15/
gt; >>
> >> For those who come from the SVN days where ci was the standard
> >> abbreviation for committing :-)
> >
> > Ah, I see. Anyway, I prefer the original name even though it violates
> > the naming policy.
> >
> > Let other express their prefere
such a scenario a fork. If someone wanted to
fork GCC they are free to do so, but changing the relationship with
GNU/FSF is not a fork, as there would continue to be one primary
source repository.
Jason
e
governed". If there is sufficient objection to the existing
leadership, developers can change it, either by negotiation for
changes with the current leadership or by forking.
The EGCS fork happened because a critical mass of developers gave up
on the GNU GCC2 leadership model. The reconciliation happened because
GNU agreed to accept the EGCS development model as GNU GCC.
I hope to resolve the current crisis by leadership adjustments
something along the lines of Ville's proposal, rather than forking.
Jason
ing the test case below from gimple.c to tree.c but there it doesn't
> even compile. I get this error (and a couple of others):
>
> In file included from /src/gcc/master/gcc/tree.c:16179:
> ./gt-tree.h: In function ‘void gt_ggc_mx(int_hash&)’:
> ./gt-tree.h:156:21: error: no matching function for call to
> ‘gt_ggc_mx(int_hash*)’
> gt_ggc_mx (&((*x)));
> ^
> So as another experiment I moved it builtins.c where it does compile
> (go figure) but then it crashes when I call it the same way from
> c_strlen().
This is because tree.c is in GTFILES, while gimple.c and tree.c are
not, so gengtype never sees the GTY decoration in the latter files.
I don't know why when it does see the GTY, it ends up trying to mark
an int_hash*.
Jason
x27;ve always preferred that name (for metaphorical consistency
with 'branch'), and there's been a wider move away from 'master' in
git repositories. I figured we could support both easily enough, but
the hooks still need updating to treat 'trunk' the same way they treat
'master'.
Jason
On Fri, Apr 23, 2021 at 7:55 AM Jakub Jelinek wrote:
>
> Status
> ==
>
> GCC 8.5 release and closing of the 8 branch is several months overdue,
> we don't have enough time to maintain trunk and 4 supported release branches.
> Therefore, I'd like to do 8.5-rc1 on 7th of May and release 8.5 and
stead of one of the other two. It seems to be used for diagnostic
messages, for which gettext will be called in the diagnostic machinery; why
use G_ instead of N_ in such cases?
Jason
On 5/13/21 6:13 PM, Jakub Jelinek wrote:
On Thu, May 13, 2021 at 06:01:39PM -0400, Jason Merrill via Gcc wrote:
I understand that the difference between the _ macro and the N_ macro is
that the former is used to force a gettext call on the argument and the
latter is used for strings for which
On 5/14/21 3:41 AM, Jakub Jelinek wrote:
On Thu, May 13, 2021 at 08:56:39PM -0400, Jason Merrill wrote:
>From 8718fbbf83978bd8ec4bf0a0e4164459158df182 Mon Sep 17 00:00:00 2001
From: Jason Merrill
Date: Thu, 13 May 2021 20:53:50 -0400
Subject: [PATCH] intl: add comments to _, N_, and G_
To:
Sorry, just pushed 3 patches before I noticed this. They're safe but not
critical, should I back them out?
On Wed, May 19, 2021 at 4:06 AM Richard Biener wrote:
>
> Status
> ==
>
> The GCC 9 branch is now frozen for the upcoming GCC 9.4 release.
> I will announce a first release candidate s
ject to get a r...@gcc.gnu.org?
>
That makes sense to me; I think overseers@ can help set up a new mailing
list.
Jason
PR100797 seems like a P1 regression from 9.3, I'd like to fix it before the
release.
On Tue, May 25, 2021 at 5:36 PM William Seurer via Gcc
wrote:
> Bootstrapped and tested it on powerpc64 power 7 and 8 BE and 8, 9, and
> 10 LE and saw nothing untoward.
>
> On 5/19/21 5:28 AM, Richard Biener wro
On 5/27/21 11:59 PM, Jason Merrill wrote:
PR100797 seems like a P1 regression from 9.3, I'd like to fix it before
the release.
Here's a candidate patch. Going to bed now.
Jason
>From c5e228d0b49154e78feb8f64659ce491bdf118c1 Mon Sep 17 00:00:00 2001
From: Jason Merrill
Date: Thu
hout needing permission from anyone.
But GPL3 has been a good license for GCC; giving up the theoretical ability
to change the license (other than to a later GPL) does not seem like a
significant loss.
Jason
Your employer is very welcome to continue to contribute under the same
legal setup.
Derived versions of GCC could already include code that was not assigned to
the FSF; even the official GCC distribution itself has long included
non-FSF-assigned code in various runtime libraries.
The change is that now we will also be able to incorporate such code into
the source code repository for the compiler.
Jason
er and the runtimes, and the runtimes
are all either GPL3+GCC Runtime Exception or under a permissive license, so
moving code between them isn't a problem. As far as I know, we have never
asked the FSF to relicense anything since the GPL3 move except for the
target macro documentation strings, which are easily handled by changing
them in both places at once.
Jason
ncy is happy to share their knowledge and discuss policy
> issues with the GCC community if we decide we want their input.
>
This seems to me a complement rather than an alternative; some Linux
developers use the Conservancy copyleft services while contributing under
the DCO, and some GCC developers could do the same.
Jason
On Thu, Jun 3, 2021 at 10:46 AM Giacomo Tesio wrote:
>
> I would have really appreciated if the GCC SC had announced such change
> for the upcoming GCC 12 while sticking to the old policy in GCC 11.
>
That is how I was thinking of the change, but I agree that it needs
clarification.
Jason
ting GCC, it's going to be in
some sort of package format that is also a convenient medium for
redistributing the source. If you aren't redistributing GCC, just using
it, then the GPL places no restrictions on you anyway.
Jason
On Mon, Jun 7, 2021 at 12:12 PM Giacomo Tesio wrote:
>
>
> On June 7, 2021 3:45:49 PM UTC, Jason Merrill wrote:
> > On Mon, Jun 7, 2021 at 11:23 AM Giacomo Tesio
> > wrote:
> >
> > > > So, a few extra copyright holders under DCO instead of assignmen
;
void b() {};
};
#pragma GCC diagnostic pop
But I also agree that GCC shouldn't warn here.
Jason
On Fri, Jun 11, 2021 at 4:03 PM Jason Merrill wrote:
> On 6/11/21 3:37 PM, Markus Faehling wrote:
> > Hello,
> >
> > I'm currently facing a problem where I cannot get both gcc and clang
> > warning-free simultaneously in my project. My code looks somewhat l
describe.)
>
> The word that comes to mind is Technophobia. Is it wise to trust
> compilers to transform programs from their source form into
> executables? What if there are bugs in either? What about the OS?
> The whole computer, or the Internet? Our cars? Fortunately, there's
> more to gain than to lose by trusting automation. If there weren't
> human progress would be stuck sometime in the 1700's.
>
> But we're not talking about anything anywhere that sophisticated
> here: a sed script to copy and paste a piece of text in
> the description of a change from one place to another. It's been
> done a few times before with more important data than ChangeLogs.
>
git gcc-commit-mklog already automates most of the process. It could also
automate adding [PRx] to the first line. Is that what you're asking
for?
Jason
On 6/15/21 11:42 PM, Jason Merrill wrote:
On Tue, Jun 15, 2021 at 10:04 PM Martin Sebor via Gcc <mailto:gcc@gcc.gnu.org>> wrote:
On 6/15/21 6:56 PM, Hans-Peter Nilsson wrote:
> On Fri, 11 Jun 2021, Martin Sebor via Gcc wrote:
>
>> On 6/11/21 11:32 AM,
On Wed, Jun 16, 2021 at 5:46 PM Martin Sebor wrote:
> On 6/16/21 2:49 PM, Jason Merrill wrote:
> > On 6/15/21 11:42 PM, Jason Merrill wrote:
> >> On Tue, Jun 15, 2021 at 10:04 PM Martin Sebor via Gcc >> <mailto:gcc@gcc.gnu.org>> wrote:
> >>
> >&g
On 6/16/21 8:17 PM, Martin Sebor wrote:
On 6/16/21 5:45 PM, Jason Merrill wrote:
On Wed, Jun 16, 2021 at 5:46 PM Martin Sebor <mailto:mse...@gmail.com>> wrote:
On 6/16/21 2:49 PM, Jason Merrill wrote:
> On 6/15/21 11:42 PM, Jason Merrill wrote:
>> On Tue, Jun 15
On 6/16/21 9:01 PM, Martin Sebor wrote:
On 6/16/21 6:40 PM, Jason Merrill wrote:
On 6/16/21 8:17 PM, Martin Sebor wrote:
On 6/16/21 5:45 PM, Jason Merrill wrote:
On Wed, Jun 16, 2021 at 5:46 PM Martin Sebor <mailto:mse...@gmail.com>> wrote:
On 6/16/21 2:49 PM, Jason Merr
cautious about adding such automation. But
there isn't any now; the only danger is of an unrelated patch showing up in
a comment on a PR. Which we already get when I mess up the PR number in my
test (oops).
Jason
d line in addition
>(currently, they are only extracted from the testsuite patches)
>
This bit seems unnecessary to me, since we want the commit to include tests
that identify the PR.
Martin Sebor's patch to extract the PR number from the testcase filename,
as an alternative to a comment, should be enough.
Jason
I am pleased to announce that the GCC Steering Committee has appointed
Hongtao Liu as maintainer of the i386 vector extensions in GCC.
Hongtao, please update your listing in the MAINTAINERS file.
Cheers,
Jason
nd passing data through env.
variable?
The hook seems like the way to adjust the commit message, and we can't
affect its command line arguments, so we're left with environment
variables or a file somewhere for communicating to it.
Jason
return
> Once something is considered a ChangeLog part, everything after it has
> to be a valid ChangeLog entry format.
> Matching just PR component/N with random text afterwards at the start
> of line or even somewhere in the middle would trigger any time one talks
> about some
> PR in the description.
>
But this *could* accept ^PR comp/N - descr$ , it just doesn't currently.
There's certainly a lot of precedent for including the description in the
PR line in ChangeLog files.
I agree we don't want to match a PR number in the middle of the line, or
without the dash.
Jason
401 - 500 of 587 matches
Mail list logo
