| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
GCC 9 in promoting it to an error by default.
llvm-svn: 367255
|
| |
|
|
| |
llvm-svn: 356987
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
While building openJDK11u, it seems that some of the code in the
native core libraries make liberal use of integer to pointer
comparisons. We currently have no flag to disabled this warning.
This add such a flag.
Patch by Kader (abdoul-kader keita)
Differential Revision: https://reviews.llvm.org/D56241
llvm-svn: 351082
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
warn_call_to_pure_virtual_member_function_from_ctor_dtor, so it can be turned into an error using Werror
Summary: Patch by Arnaud Bienner
Reviewers: davide, rsmith, jkorous
Reviewed By: jkorous
Subscribers: jkorous, sylvestre.ledru, cfe-commits
Differential Revision: https://reviews.llvm.org/D53807
llvm-svn: 347555
|
| |
|
|
|
|
|
|
|
|
| |
The C standard doesn't allow comparisons like "f1 < f2" (where f1 and f2
are function pointers), but we allow them as an extension. Add a
warning flag to control this warning.
Differential Revision: https://reviews.llvm.org/D46155
llvm-svn: 331570
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Found via codespell -q 3 -I ../clang-whitelist.txt
Where whitelist consists of:
archtype
cas
classs
checkk
compres
definit
frome
iff
inteval
ith
lod
methode
nd
optin
ot
pres
statics
te
thru
Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few
files that have dubious fixes reverted.)
Differential revision: https://reviews.llvm.org/D44188
llvm-svn: 329399
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
function declarations.
We were injecting the function into the wrong semantic context, resulting in it
failing to be registered as a global for redeclaration lookup. As a
consequence, we accepted invalid code since r310616.
Fixing that resulted in the "out-of-scope declaration" diagnostic firing a lot
more often. It turned out that warning codepath was non-conforming, because it
did not cause us to inject the implicitly-declared function into the enclosing
block scope. We now only warn if the type of the out-of-scope declaration
doesn't match the type of an implicitly-declared function; in all other cases,
we produce the normal warning for an implicitly-declared function.
llvm-svn: 314871
|
| |
|
|
| |
llvm-svn: 302443
|
| |
|
|
|
|
| |
primary template" error (since Eigen hits it), and while I'm here also add a warning flag for "partial specialization is not usable because one or more of its parameters cannot be deduced" warning.
llvm-svn: 290625
|
| |
|
|
|
|
|
|
|
|
|
|
| |
As a first step toward removing Objective-C garbage collection from
Clang, remove support from the driver. I'm hoping this will flush out
any expected bots/configurations/whatever that might rely on it.
I've left the options behind temporarily in -cc1 to keep tests passing.
I'll kill them off entirely in a follow up when I've had a chance to
update/delete the rest of Clang.
llvm-svn: 288872
|
| |
|
|
|
|
| |
In passing, add a warning group for "ignored qualifier in inline assembly" warnings.
llvm-svn: 288548
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Expose a warning flag for warn_duplicate_protocol_def. This allows control
over the severity of duplicate protocol definitions.
For example -Werror=duplicate-protocol or
#pragma clang diagnostic ignored "-Wduplicate-protocol".
Patch provided by Dave Lee!
Differential Revision: https://reviews.llvm.org/D26406
llvm-svn: 286487
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This has two significant effects:
1) Direct relational comparisons between null pointer constants (0 and nullopt)
and pointers are now ill-formed. This was always the case for C, and it
appears that C++ only ever permitted by accident. For instance, cases like
nullptr < &a
are now rejected.
2) Comparisons and conditional operators between differently-cv-qualified
pointer types now work, and produce a composite type that both source
pointer types can convert to (when possible). For instance, comparison
between 'int **' and 'const int **' is now valid, and uses an intermediate
type of 'const int *const *'.
Clang previously supported #2 as an extension.
We do not accept the cases in #1 as an extension. I've tested a fair amount of
code to check that this doesn't break it, but if it turns out that someone is
relying on this, we can easily add it back as an extension.
This is a re-commit of r284800.
llvm-svn: 284890
|
| |
|
|
|
|
|
|
| |
rules."
This reverts commit r284800, as it failed all ARM/AArch64 bots.
llvm-svn: 284811
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This has two significant effects:
1) Direct relational comparisons between null pointer constants (0 and nullopt)
and pointers are now ill-formed. This was always the case for C, and it
appears that C++ only ever permitted by accident. For instance, cases like
nullptr < &a
are now rejected.
2) Comparisons and conditional operators between differently-cv-qualified
pointer types now work, and produce a composite type that both source
pointer types can convert to (when possible). For instance, comparison
between 'int **' and 'const int **' is now valid, and uses an intermediate
type of 'const int *const *'.
Clang previously supported #2 as an extension.
We do not accept the cases in #1 as an extension. I've tested a fair amount of
code to check that this doesn't break it, but if it turns out that someone is
relying on this, we can easily add it back as an extension.
llvm-svn: 284800
|
| |
|
|
|
|
| |
The warning I added in r282426 should be a diagnostic group.
llvm-svn: 282557
|
| |
|
|
|
|
|
|
|
| |
This option behaves in a similar spirit as -save-temps and writes
internal llvm statistics in json format to a file.
Differential Revision: https://reviews.llvm.org/D24820
llvm-svn: 282426
|
| |
|
|
| |
llvm-svn: 253119
|
| |
|
|
| |
llvm-svn: 250105
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
specification) to an error. No compiler other than Clang seems to allow this,
and it doesn't seem like a useful thing to accept as an extension in general.
The current behavior was added for PR5957, where the problem was specifically
related to mismatches of the exception specification on the implicitly-declared
global operator new and delete. To retain that workaround, we downgrade the
error to an ExtWarn when the declaration is of a replaceable global allocation
function.
Now that this is an error, stop trying (and failing) to recover from a missing
computed noexcept specification. That recovery didn't work, and led to crashes
in code like the added testcase.
llvm-svn: 248867
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Implement DR262 (for C). This patch will mainly affect bitfields of type _Bool
Reviewers: fraggamuffin, rsmith
Subscribers: hubert.reinterpretcast, cfe-commits
Differential Revision: http://reviews.llvm.org/D10018
llvm-svn: 247618
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we build with -Werror=implicit-function-declaration, only implicit
function declarations of non-library functions throw compiler errors.
For library functions, we only produce a warning. There is no way to
promote both of these cases to an error without promoting other
warnings.
It makes little sense to introduce an additional compiler flag just to
control this specific warning. In my opinion it should just be part of
the same group.
llvm-svn: 246857
|
| |
|
|
|
|
| |
hierarchy inversion with regards to other catch handlers for the same block.
llvm-svn: 234375
|
| |
|
|
| |
llvm-svn: 229338
|
| |
|
|
|
|
| |
macro. NFC; Clang edition.
llvm-svn: 229336
|
| |
|
|
|
|
|
|
| |
based on whether "redundant" braces are ever reasonable as part of the
initialization of the entity, rather than whether the initialization is
"top-level". In passing, add a warning flag for it.
llvm-svn: 228896
|
| |
|
|
|
|
|
| |
on multiple selector names found during lookup.
rdar://19265296
llvm-svn: 224536
|
| |
|
|
|
|
| |
rdar://19116886
llvm-svn: 223168
|
| |
|
|
|
|
| |
This fixes PR21340.
llvm-svn: 220442
|
| |
|
|
|
|
| |
warn_property_types_are_incompatible. rdar://18487506
llvm-svn: 218621
|
| |
|
|
|
|
|
| |
One more, and the number of flags without a dedicated flag fits in two decimal
digits :-)
llvm-svn: 215946
|
| |
|
|
|
|
| |
mismatch. //rdar://17845264
llvm-svn: 214203
|
| |
|
|
|
|
|
|
| |
ExtWarn/Warnings. Mostly the name of the warning was changed to match the
semantics, but in the PR20356 cases, the warning was about valid code, so the
diagnostic was changed from ExtWarn to Warning instead.
llvm-svn: 213443
|
| |
|
|
|
|
|
|
|
|
|
| |
CL permits static redeclarations to follow extern declarations. The
storage specifier on the latter declaration has no effect.
This fixes PR20034.
Differential Revision: http://reviews.llvm.org/D4149
llvm-svn: 211238
|
| |
|
|
|
|
|
| |
This diagnostic is now controlled solely by -no-ns-alloc-error thus matching
the original intended behaviour.
llvm-svn: 209184
|
| |
|
|
|
|
|
|
|
|
|
| |
This is consistent with -Wbuiltin-macro-redefined, and puts this common
extension warning under a flag.
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D3283
llvm-svn: 205591
|
| |
|
|
|
|
|
|
| |
(for an integer too large for any signed type) from Warning to ExtWarn -- it's
ill-formed in C++11 and C99 onwards, and UB during translation in C89 and
C++98. Add diagnostic groups for two relevant diagnostics.
llvm-svn: 203974
|
| |
|
|
|
|
|
|
| |
This warning was missing a flag, add one.
test/Misc/warning-flags.c has one fewer entry.
llvm-svn: 203522
|
| |
|
|
|
|
|
| |
Also promote a couple of Warnings on ill-formed code found by this testing to
ExtWarns.
llvm-svn: 203021
|
| |
|
|
|
|
|
| |
Create a new diagnostic, -Wignored-pragmas and use it to handle any
case where a pragma would have a side effect but is ignored.
llvm-svn: 201102
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This starts to switch ARCMT to use proper diagnostic messages. The old use was
based on incorrect example code from the documentation.
The logic of the previous report() functions has been retained to support any
external consumers that might be intercepting diagnostic messages through the
old interface.
Note that the change in test/Misc/warning-flags.c isn't a new warning without a
flag, rather one that was previously invisible to the test. Adding a flag might
be a good idea though.
llvm-svn: 200124
|
| |
|
|
|
|
|
|
| |
coverage. Parameterized the diagnostic, and made it more consistent with other attribute diagnostic wordings. Added test coverage.
Since this warning was generalized, it was also given a sensible warning group flag and the corresponding test was updated to reflect this.
llvm-svn: 198053
|
| |
|
|
| |
llvm-svn: 197736
|
| |
|
|
| |
llvm-svn: 195095
|
| |
|
|
| |
llvm-svn: 194498
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds the following, more specific warning flags:
gnu-anonymous-struct
gnu-compound-literal-initializer
gnu-empty-struct
gnu-flexible-array-initializer
gnu-flexible-array-union-member
gnu-folding-constant
redeclared-class-member
gnu-redeclared-enum
gnu-union-cast
gnu-variable-sized-type-not-at-end
Patch by Peter Lewis.
llvm-svn: 190972
|
| |
|
|
|
|
| |
arguments to map strings to the proper enumeration value. This makes error checking more consistent and reduces the amount of hand-written code required.
llvm-svn: 190545
|
| |
|
|
|
|
| |
explicit template instantiation" warning.
llvm-svn: 189893
|
| |
|
|
|
|
|
|
| |
It turns out that Plum Hall depends on us not emitting an error on
integer literals which fit into long long, but fit into
unsigned long long. So C99 conformance requires not conforming to C99. :)
llvm-svn: 187172
|
| |
|
|
|
|
| |
Also, fix the wording to reflect this.
llvm-svn: 187171
|