Alvaro Herrera writes:
> Fixed one straggler in contrib, and while testing it I realized why
> ccache doesn't pay attention to the changes I was doing in the file:
> ccache compares the *preprocessed* version of the file and only if that
> differs from the version that was cached last, ccache
Alvaro Herrera writes:
> I ended up using level 4 and dialling back to 3 for zic.c only
> (different make trickery though).
Meh ... if we're going to use level 4, I'm inclined to just change zic.c
to match. It's not like we're using the upstream code verbatim anyway.
We could easily add
On 2020-May-12, Alvaro Herrera wrote:
> I get no warnings with this (gcc 8), but ccache seems to save warnings
> in one run so that they can be thrown in a later one. I'm not sure what
> to make of that, but ccache -d proved that beyond reasonable doubt and
> ccache -clear got rid of the lot.
On 2020-May-11, Julien Rouhaud wrote:
> On Mon, May 11, 2020 at 4:40 PM Tom Lane wrote:
> >
> > Julien Rouhaud writes:
> > > On Mon, May 11, 2020 at 3:41 PM Tom Lane wrote:
> > >> Why? It uses "fallthrough" which is a legal spelling per level 4.
> >
> > > GCC documentation mentions [
On Mon, May 11, 2020 at 4:40 PM Tom Lane wrote:
>
> Julien Rouhaud writes:
> > On Mon, May 11, 2020 at 3:41 PM Tom Lane wrote:
> >> Why? It uses "fallthrough" which is a legal spelling per level 4.
>
> > GCC documentation mentions [ \t]*FALLTHR(OUGH|U)[ \t]* for level 4
> > (out of the view
Julien Rouhaud writes:
> On Mon, May 11, 2020 at 3:41 PM Tom Lane wrote:
>> Why? It uses "fallthrough" which is a legal spelling per level 4.
> GCC documentation mentions [ \t]*FALLTHR(OUGH|U)[ \t]* for level 4
> (out of the view other alternatives), which AFAICT is case sensitive
> (level 3
On Mon, May 11, 2020 at 3:41 PM Tom Lane wrote:
>
> Julien Rouhaud writes:
> > Note that timezone/zic.c would also have to be changed.
>
> Why? It uses "fallthrough" which is a legal spelling per level 4.
GCC documentation mentions [ \t]*FALLTHR(OUGH|U)[ \t]* for level 4
(out of the view other
Julien Rouhaud writes:
> Note that timezone/zic.c would also have to be changed.
Why? It uses "fallthrough" which is a legal spelling per level 4.
regards, tom lane
On Mon, May 11, 2020 at 2:07 PM Andrew Dunstan
wrote:
>
>
> On 5/11/20 7:29 AM, Julien Rouhaud wrote:
> > On Mon, May 11, 2020 at 6:47 AM Tom Lane wrote:
> >> Alvaro Herrera writes:
> >>> On 2020-May-06, Alvaro Herrera wrote:
> This doesn't allow whitespace between "fall" and "through",
On 5/11/20 7:29 AM, Julien Rouhaud wrote:
> On Mon, May 11, 2020 at 6:47 AM Tom Lane wrote:
>> Alvaro Herrera writes:
>>> On 2020-May-06, Alvaro Herrera wrote:
This doesn't allow whitespace between "fall" and "through", which means
we generate 217 such warnings currently. Or we can
On Mon, May 11, 2020 at 6:47 AM Tom Lane wrote:
>
> Alvaro Herrera writes:
> > On 2020-May-06, Alvaro Herrera wrote:
> >> This doesn't allow whitespace between "fall" and "through", which means
> >> we generate 217 such warnings currently. Or we can just use
> >> -Wimplicit-fallthrough=3, which
Alvaro Herrera writes:
> On 2020-May-06, Alvaro Herrera wrote:
>> This doesn't allow whitespace between "fall" and "through", which means
>> we generate 217 such warnings currently. Or we can just use
>> -Wimplicit-fallthrough=3, which does allow whitespace (among other
>> detritus).
> If we're
On 2020-May-06, Alvaro Herrera wrote:
> This doesn't allow whitespace between "fall" and "through", which means
> we generate 217 such warnings currently. Or we can just use
> -Wimplicit-fallthrough=3, which does allow whitespace (among other
> detritus).
If we're OK with patching all those
On 2020-Apr-12, Tom Lane wrote:
> The only more-restrictive alternative, short of disabling
> the comments altogether, is
>
>* -Wimplicit-fallthrough=4 case sensitively matches one of the
>following regular expressions:
>
>*<"-fallthrough">
>
Alvaro Herrera writes:
> Do we intend to see this done in the current cycle?
I don't have an objection to doing it now. It's just a new compiler
warning option, it shouldn't be able to break any code. (Plus there's
plenty of time to revert, if somehow it causes a problem.)
Do we intend to see this done in the current cycle?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Sun, Apr 12, 2020 at 5:25 PM Mark Dilger
wrote:
>
> > On Apr 12, 2020, at 7:55 AM, Tom Lane wrote:
> >
> > Poking around in the archives, it seems like the only previous formal
> > proposal to add -Wimplicit-fallthrough was in the context of a much
> > more aggressive proposal to make a lot
> On Apr 12, 2020, at 7:55 AM, Tom Lane wrote:
>
> Poking around in the archives, it seems like the only previous formal
> proposal to add -Wimplicit-fallthrough was in the context of a much
> more aggressive proposal to make a lot of non-Wall warnings into
> errors [1], which people did not
Julien Rouhaud writes:
> On Sat, Apr 11, 2020 at 02:47:34PM -0400, Tom Lane wrote:
>> Yeah, assorted buildfarm animals are mentioning that too. I wonder
>> if we should add that to the default warning options selected by
>> configure? I don't remember if that's been discussed before.
> I'm all
On Sat, Apr 11, 2020 at 02:47:34PM -0400, Tom Lane wrote:
> Julien Rouhaud writes:
> > On Tue, Apr 7, 2020 at 10:28 PM Alvaro Herrera
> > wrote:
> >> Support FETCH FIRST WITH TIES
>
> > FTR I now get the following when compiling with -Wimplicit-fallthrough
> > -Werror:
>
> Yeah, assorted
20 matches
Mail list logo
