On Fri, Dec 28, 2018 at 2:57 AM Nico Weber wrote:
>
> Should this be in -Wextra-semi? It seems weird to have to pass both
> -Wextra-semi and -Wextra-semi-stmt.
It does seem somewhat weird, and my initial implementation did add it
into -Wextra-semi,
but the review https://reviews.llvm.org/D52695#i
Should this be in -Wextra-semi? It seems weird to have to pass both
-Wextra-semi and -Wextra-semi-stmt.
(Also, we generally try to not add DefaultIgnore warnings. I think this is
a useful warning though, and other than others in this thread I think it'd
be good to have -Wextra-semi in -Wall. But I
On Wed, 5 Dec 2018 at 11:14, Alex L via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> We have about 100k unique occurrences of this warning across a slice of
> our software stack. It's simply not feasible to us to adopt it, so we would
> prefer for it to be reverted to avoid downstream diverg
Nobody should be using "-Weverything" in their default build flags! It
should only be used as a way to find the names of interesting warning
flags. I'd note that "-Weverything" even has warnings that _conflict_ with
each-other...
It's unworkable for clang to have a policy which prevents the additi
On Wed, Dec 5, 2018 at 2:14 PM Alex L via cfe-commits
wrote:
>
> We have about 100k unique occurrences of this warning across a slice of our
> software stack. It's simply not feasible to us to adopt it, so we would
> prefer for it to be reverted to avoid downstream divergence in Apple's clang.
We have about 100k unique occurrences of this warning across a slice of our
software stack. It's simply not feasible to us to adopt it, so we would
prefer for it to be reverted to avoid downstream divergence in Apple's
clang. Granted, these occur in projects that use -Weverything but those
projects
On Wed, 5 Dec 2018, 10:01 George Karpenkov via cfe-commits <
cfe-commits@lists.llvm.org wrote:
> These are the cases I get:
>
> #define unexpected(a) { kprintf("unexpected %s:%d\n", __FILE__, __LINE__);
> a; }
>
> and
>
> #if 0
> #define DEBG(fmt, args...) { IOLog(fmt, ## args); kprintf(fmt,
These are the cases I get:
#define unexpected(a) { kprintf("unexpected %s:%d\n", __FILE__, __LINE__); a; }
and
#if 0
#define DEBG(fmt, args...) { IOLog(fmt, ## args); kprintf(fmt, ## args); }
#else
#define DEBG(fmt, args...) {}
#endif
Now calls
`DEBG(‘x’);` and `unexpected(‘msg’);`
On Wed, Dec 5, 2018 at 1:40 AM Roman Lebedev wrote:
>
> On Wed, Dec 5, 2018 at 4:07 AM Artem Dergachev via cfe-commits
> wrote:
> >
> >
> >
> > On 12/4/18 5:04 PM, George Karpenkov via cfe-dev wrote:
> > >
> > >> On Dec 4, 2018, at 4:47 PM, Aaron Ballman wrote:
> > >>
> > >> On Tue, Dec 4, 2018
On Wed, Dec 5, 2018 at 4:07 AM Artem Dergachev via cfe-commits
wrote:
>
>
>
> On 12/4/18 5:04 PM, George Karpenkov via cfe-dev wrote:
> >
> >> On Dec 4, 2018, at 4:47 PM, Aaron Ballman wrote:
> >>
> >> On Tue, Dec 4, 2018 at 7:35 PM George Karpenkov
> >> wrote:
> >>> Hi Roman,
Hi.
> >>> I’m ag
On 12/4/18 5:04 PM, George Karpenkov via cfe-dev wrote:
On Dec 4, 2018, at 4:47 PM, Aaron Ballman wrote:
On Tue, Dec 4, 2018 at 7:35 PM George Karpenkov wrote:
Hi Roman,
I’m against this new warning.
A very common idiom is defining a “DEBUG” macro to be a no-op in release, and a
loggin
> On Dec 4, 2018, at 4:47 PM, Aaron Ballman wrote:
>
> On Tue, Dec 4, 2018 at 7:35 PM George Karpenkov wrote:
>>
>> Hi Roman,
>>
>> I’m against this new warning.
>>
>> A very common idiom is defining a “DEBUG” macro to be a no-op in release,
>> and a logging function otherwise.
>> The new
On Tue, Dec 4, 2018 at 7:35 PM George Karpenkov wrote:
>
> Hi Roman,
>
> I’m against this new warning.
>
> A very common idiom is defining a “DEBUG” macro to be a no-op in release, and
> a logging function otherwise.
> The new introduced warning warns on all such cases (e.g. 'DEBUG(“mystring”);')
Hi Roman,
I’m against this new warning.
A very common idiom is defining a “DEBUG” macro to be a no-op in release, and a
logging function otherwise.
The new introduced warning warns on all such cases (e.g. 'DEBUG(“mystring”);')
As noted in the review, Clang warnings should generally not be used
Author: lebedevri
Date: Tue Nov 20 10:59:05 2018
New Revision: 347339
URL: http://llvm.org/viewvc/llvm-project?rev=347339&view=rev
Log:
[clang][Parse] Diagnose useless null statements / empty init-statements
Summary:
clang has `-Wextra-semi` (D43162), which is not dictated by the currently
selec
15 matches
Mail list logo
