| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 219043
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL has caused bootstrap failures on Linux and OSX buildbots running with -Werror.
Example report from http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/13183/steps/bootstrap%20clang/logs/stdio:
================================================================
[ 91%] Building CXX object tools/clang/tools/diagtool/CMakeFiles/diagtool.dir/ShowEnabledWarnings.cpp.o
In file included from /home/dtoolsbot/build/sanitizer-x86_64-linux/build/llvm/lib/Target/R600/AMDGPUISelDAGToDAG.cpp:20:
In file included from /home/dtoolsbot/build/sanitizer-x86_64-linux/build/llvm/lib/Target/R600/SIISelLowering.h:19:
/home/dtoolsbot/build/sanitizer-x86_64-linux/build/llvm/lib/Target/R600/SIInstrInfo.h:71:8: error: 'getLdStBaseRegImmOfs' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
bool getLdStBaseRegImmOfs(MachineInstr *LdSt,
^
/home/dtoolsbot/build/sanitizer-x86_64-linux/build/llvm/include/llvm/Target/TargetInstrInfo.h:815:16: note: overridden virtual function is here
virtual bool getLdStBaseRegImmOfs(MachineInstr *LdSt,
^
================================================================
llvm-svn: 218969
|
|
|
|
|
|
|
|
|
|
|
|
| |
for an overriding method if class has at least one
'override' specified on one of its methods.
Reviewed by Doug Gregor. rdar://18295240
(I have already checked in all llvm files with missing 'override'
methods and Bob Wilson has fixed a TableGen of FastISel so
no warnings are expected from build of llvm after this patch.
I have already verified this).
llvm-svn: 218925
|
|
|
|
|
|
| |
declaration to our list of special cases.
llvm-svn: 215520
|
|
|
|
|
|
|
|
|
|
|
| |
allow this, and we should warn on it, but it turns out that people were already
relying on this.
We should introduce a -Wgcc-compat warning for this if the attributes are known
to GCC, but we don't currently track enough information about attributes to do
so reliably.
llvm-svn: 200045
|
|
|
|
|
|
|
|
|
|
| |
member-declaration. In the process, fix a couple of bugs that had crept in
where we would parse the first and subsequent member-declarators differently
(in particular, we didn't accept an asm-label on a member function definition
within a class, and we would accept virt-specifiers and attributes in the wrong
order on the first declarator but not on subsequent ones).
llvm-svn: 199957
|
|
|
|
|
|
| |
Warning for a duplicate 'constexpr' specifier.
llvm-svn: 198956
|
|
|
|
|
|
| |
and we know where they go.
llvm-svn: 193297
|
|
|
|
|
|
| |
an accidentally-included name for the declarator.
llvm-svn: 192559
|
|
|
|
|
|
|
|
|
| |
followed by an identifier, then diagnose an identifier as being a bogus part of
the declarator instead of tripping over it. Improves diagnostics for cases like
std::vector<const int *p> my_vec;
llvm-svn: 186061
|
|
|
|
|
|
|
|
|
| |
C++1y, so stop adding the 'const' there. Provide a compatibility warning for
code relying on this in C++11, with a fix-it hint. Update our lazily-written
tests to add the const, except for those ones which were testing our
implementation of this rule.
llvm-svn: 179969
|
|
|
|
|
|
| |
on the MSVC bot.
llvm-svn: 179432
|
|
|
|
|
|
| |
semantics as __thread for now.
llvm-svn: 179424
|
|
|
|
| |
llvm-svn: 172886
|
|
|
|
| |
llvm-svn: 172375
|
|
|
|
| |
llvm-svn: 171908
|
|
|
|
|
|
|
| |
dropping the specifier, just like we do for non-member functions and function
templates declared 'typedef'. Patch by Brian Brooks!
llvm-svn: 168108
|
|
|
|
| |
llvm-svn: 166152
|
|
|
|
| |
llvm-svn: 163826
|
|
|
|
|
|
| |
ExtWarn and the other a vanilla warning. This addresses PR13705, where const char const * wouldn't warn unless -pedantic was specified under the right conditions.
llvm-svn: 162793
|
|
|
|
|
|
| |
unless they appear in a decl-specifier-seq.
llvm-svn: 160688
|
|
|
|
|
|
|
|
| |
scope to -Wc++11-extensions. Move extra semicolon after member function
definition diagnostic out of -pedantic, since C++ allows a single semicolon
there. Keep it in -Wextra-semi, though, since it's still questionable.
llvm-svn: 160618
|
|
|
|
|
|
|
|
| |
being defined here: [] () -> struct S {} does not define struct S.
In passing, implement DR1318 (syntactic disambiguation of 'final').
llvm-svn: 152551
|
|
instead of a semicolon (as sometimes happens during refactorings). When such a
comma is seen at the end of a line, and is followed by something which can't
possibly be a declarator (or even something which might be a plausible typo for
a declarator), suggest that a semicolon was intended.
llvm-svn: 142544
|