| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
designator" diagnostic with more correct and more human-friendly "cannot take
address of rvalue of type 'T'".
For the case of & &T::f, provide a custom diagnostic, rather than unhelpfully
saying "cannot take address of rvalue of type '<overloaded function type>'".
For the case of &array_temporary, treat it just like a class temporary
(including allowing it as an extension); the existing diagnostic wording
for the class temporary case works fine.
llvm-svn: 174262
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 173510
|
|
|
|
|
|
| |
suggestion.
llvm-svn: 173367
|
|
|
|
| |
llvm-svn: 173198
|
|
|
|
| |
llvm-svn: 173193
|
|
|
|
| |
llvm-svn: 173190
|
|
|
|
|
|
| |
supported.
llvm-svn: 173177
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 172545
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
attributes appertain to a declaration, even though they would be much more
naturally modelled as appertaining to a function type. Previously, we would
try to distribute them from the declarator to the function type, then
reject them for being at an incorrect location. Now, we just distribute them
as far as the declarator; the existing attribute handling code can actually
apply them there just fine.
llvm-svn: 172504
|
|
|
|
|
|
|
|
|
|
|
| |
1) Supported by Clang, and
2) Supported by GCC, and
3) Documented in GCC's manual.
g++ allows its C++11-style attributes to appertain only to the entity being
declared, and never to a type (even for a type attribute), so we do the same.
llvm-svn: 172382
|
|
|
|
| |
llvm-svn: 172375
|
|
|
|
| |
llvm-svn: 171908
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Add OpenCL images as clang builtin types.
llvm-svn: 170432
|
|
|
|
|
|
| |
these files to Windows style.
llvm-svn: 170431
|
|
|
|
| |
llvm-svn: 170428
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
of the file.
llvm-svn: 169688
|
|
|
|
|
|
|
|
| |
option. MS-style inline asm can now be enabled by either -fasm-blocks or
-fms-extensions.
rdar://12808010
llvm-svn: 169445
|
|
|
|
|
|
|
| |
-fasm-blocks flag, not the -fms-extensions flag.
rdar://12808010
llvm-svn: 169422
|
|
|
|
|
|
|
| |
Our error recovery path may have made the class anonymous, and that has a pretty
disastrous impact on any attempt to parse a class body containing constructors.
llvm-svn: 169374
|
|
|
|
|
|
| |
appertains to a friend declaration, that declaration shall be a definition.
llvm-svn: 168826
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
syntactic locations around class specifiers.
This change list implemented logic that explicitly detects several combinations of locations where C++11 attribute
specifiers might be incorrectly placed within a class specifier. Previously we emit generic diagnostics like
"expected identifier" for such cases; now we emit specific diagnostic against the misplaced attributes, this also
fixed a bug in old code where attributes appear at legitimate locations were incorrectly rejected.
Thanks to Richard Smith for reviewing!
llvm-svn: 168626
|
|
|
|
| |
llvm-svn: 168267
|
|
|
|
|
|
|
| |
dropping the specifier, just like we do for non-member functions and function
templates declared 'typedef'. Patch by Brian Brooks!
llvm-svn: 168108
|
|
|
|
|
|
|
|
|
| |
specifiers.
We don't support any C++11 attributes that appertain to declaration specifiers so reject
the attributes in parser until we support them; this also conforms to what g++ 4.8 is doing.
llvm-svn: 167481
|
|
|
|
| |
llvm-svn: 167379
|
|
|
|
| |
llvm-svn: 167369
|
|
|
|
| |
llvm-svn: 167320
|
|
|
|
|
|
|
| |
')', if found. Don't crash.
Fixes PR11852.
llvm-svn: 167268
|
|
|
|
|
|
| |
Patch from Brian Brooks <brooks.brian@gmail.com>!
llvm-svn: 166893
|
|
|
|
|
|
| |
(so that it can have additional options set when trying to debug issues causing regressions).
llvm-svn: 166681
|
|
|
|
|
|
| |
this, for better error recovery.
llvm-svn: 166645
|
|
|
|
| |
llvm-svn: 166619
|
|
|
|
|
|
| |
the suggestions.
llvm-svn: 166400
|
|
|
|
|
|
|
| |
declarations and statements. Emit an error if the FP_CONTRACT is used
later in a compound statement.
llvm-svn: 166383
|
|
|
|
|
|
| |
literal-operator-id.
llvm-svn: 166373
|
|
|
|
|
|
| |
VerifyDiagnosticConsumer, make the necessary adjustment to 580 test-cases which will henceforth require this new directive.
llvm-svn: 166280
|
|
|
|
| |
llvm-svn: 166152
|
|
|
|
| |
llvm-svn: 165810
|