| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
-Wimplicit-fallthrough)
llvm-svn: 174202
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the member has an initializer, assume it was probably intended to be static
and suggest/recover with that.
If the member doesn't have an initializer, assume it was probably intended to
be const instead of constexpr and suggest that.
(if the attempt to apply these changes fails, don't make any suggestion &
produce the same diagnostic experience as before. The only case where this can
come up that I know of is with a mutable constexpr with an initializer, since
mutable is incompatible with static (but it's already incompatible with
const anyway))
llvm-svn: 173873
|
| |
|
|
|
|
| |
C++11 allows that.
llvm-svn: 173789
|
| |
|
|
|
|
|
|
|
| |
the diagnostic's warn_ name. Switch some places (notably C++11 attributes)
which really wanted an error over to a different diagnostic. Finally, suppress
the diagnostic entirely for __ptr32, __ptr64 and __w64, to avoid producing
diagnostics in important system headers.
llvm-svn: 173788
|
| |
|
|
| |
llvm-svn: 173779
|
| |
|
|
|
|
|
| |
It turns out that there's no correctness bug here (because we can't have a type
definition in this location), but there was a diagnostic bug.
llvm-svn: 173766
|
| |
|
|
|
|
|
| |
pretty-print them properly (modulo the more general badness in alignment
attribute printing).
llvm-svn: 173752
|
| |
|
|
|
|
|
|
|
| |
as a keyword. Rationalize existing attributes to use it as appropriate, and to
not lie about some __declspec attributes being GNU attributes. In passing,
remove a gross hack which was discarding attributes which we could handle. This
results in us actually respecting the __pascal keyword again.
llvm-svn: 173746
|
| |
|
|
|
|
|
|
|
|
| |
This required plumbing through a new flag to determine whether a ParmVarDecl is
actually a parameter of a function declaration (as opposed to a function
typedef etc, where the attribute is prohibited). Weirdly, this attribute (just
like [[noreturn]]) cannot be applied to a function type, just to a function
declaration (and its parameters).
llvm-svn: 173726
|
| |
|
|
|
|
|
| |
on a type. Currently, it gives a generic "expected unqualified-id" error.
The new error message is "cannot use (dot|arrow) operator on a type".
llvm-svn: 173556
|
| |
|
|
|
|
| |
inline assembly can be enable with -fasm-blocks or -fms-extensions alone.
llvm-svn: 173186
|
| |
|
|
|
|
|
| |
an unimplemented selector is consumed by
"respondsToSelector:". // rdar://12938616
llvm-svn: 173179
|
| |
|
|
|
|
| |
supported.
llvm-svn: 173177
|
| |
|
|
|
|
|
| |
an unimplemented selector is consumed by
"respondsToSelector:". // rdar://12938616
llvm-svn: 173097
|
| |
|
|
|
|
| |
OpenCL restrictions (OpenCL 1.2 spec 6.9)
llvm-svn: 172973
|
| |
|
|
| |
llvm-svn: 172886
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
r159549 / r159164 regressed clang to reject
struct s {};
struct s
operator++(struct s a)
{ return a; }
This fixes the regression. Richard, pleas check if this looks right.
llvm-svn: 172834
|
| |
|
|
| |
llvm-svn: 172761
|
| |
|
|
| |
llvm-svn: 172701
|
| |
|
|
|
|
|
|
| |
it apart from [[gnu::noreturn]] / __attribute__((noreturn)), since their
semantics are not equivalent (for instance, we treat [[gnu::noreturn]] as
affecting the function type, whereas [[noreturn]] does not).
llvm-svn: 172691
|
| |
|
|
|
|
|
|
|
|
|
| |
with function definitions.
We really should remove Parser::isDeclarationAfterDeclarator entirely, since
it's meaningless in C++11 (an open brace could be either a function definition
or an initializer, which is what it's trying to differentiate between). The
other caller of it happens to be correct right now...
llvm-svn: 172510
|
| |
|
|
|
|
|
|
| |
ActOnFinishFullExpr that some of its checks only apply to discarded-value
expressions. This adds missing checks for unexpanded variadic template
parameter packs to a handful of constructs.
llvm-svn: 172485
|
| |
|
|
| |
llvm-svn: 172375
|
| |
|
|
|
|
| |
brought into 'clang' namespace by clang/Basic/LLVM.h
llvm-svn: 172323
|
| |
|
|
|
|
| |
functionality change.
llvm-svn: 172185
|
| |
|
|
|
|
|
| |
Parser::ParseTranslationUnit is now dead because the loop over
ParseTopLevelDecl is in ParseAST.
llvm-svn: 172005
|
| |
|
|
| |
llvm-svn: 171908
|
| |
|
|
| |
llvm-svn: 171895
|
| |
|
|
| |
llvm-svn: 171894
|
| |
|
|
|
|
|
|
|
|
| |
Following r168626, in class declaration or definition, there are a combination of syntactic locations
where C++11 attributes could appear, and among those the only valid location permitted by standard is
between class-key and class-name. So for those attributes appear at wrong locations, fixit is used to
move them to expected location and we recover by applying them to the class specifier.
llvm-svn: 171757
|
| |
|
|
|
|
| |
nearby 'C++0x' comments.
llvm-svn: 171372
|
| |
|
|
| |
llvm-svn: 171367
|
| |
|
|
|
|
|
| |
These got deleted late 2010 during the Actions/Sema unification.
No functionality change.
llvm-svn: 171269
|
| |
|
|
| |
llvm-svn: 171268
|
| |
|
|
|
|
|
|
| |
DS parameter has a default (null) value anyway, so there's no need for an
if/else here.
Patch by Nikola Smiljanić.
llvm-svn: 171210
|
| |
|
|
| |
llvm-svn: 170933
|
| |
|
|
| |
llvm-svn: 170925
|
| |
|
|
| |
llvm-svn: 170924
|
| |
|
|
| |
llvm-svn: 170918
|
| |
|
|
| |
llvm-svn: 170761
|
| |
|
|
|
|
|
| |
Thereby, it can be reused by clang-format and others.
Review: http://llvm-reviews.chandlerc.com/D229
llvm-svn: 170757
|
| |
|
|
|
|
| |
which is wrong here.
llvm-svn: 170721
|
| |
|
|
|
|
| |
single attribute in the future.
llvm-svn: 170500
|
| |
|
|
|
|
| |
Add OpenCL images as clang builtin types.
llvm-svn: 170432
|
| |
|
|
|
|
| |
these files to Windows style.
llvm-svn: 170431
|
| |
|
|
| |
llvm-svn: 170428
|
| |
|
|
| |
llvm-svn: 170363
|
| |
|
|
|
|
|
|
| |
C++11 allowed writing "vector<vector<int>>" without a space between the two ">".
This change allows this for protocols in template lists too in -std=c++11 mode,
and improves the diagnostic in c++98 mode.
llvm-svn: 170223
|
| |
|
|
| |
llvm-svn: 170176
|
| |
|
|
|
|
| |
latter is rather a mess to type.
llvm-svn: 169919
|