| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
a non-variable iteration declaration.
llvm-svn: 179053
|
| |
|
|
| |
llvm-svn: 178720
|
| |
|
|
| |
llvm-svn: 178670
|
| |
|
|
|
|
|
|
| |
smarts so that it doesn't approve of keywords and/or type names when it
knows (based on its flags) that those kinds of corrections are not
wanted.
llvm-svn: 178668
|
| |
|
|
|
|
| |
C11 6.7.2.1p1).
llvm-svn: 178632
|
| |
|
|
| |
llvm-svn: 178631
|
| |
|
|
|
|
|
|
| |
warning when doing a __bride cast in non-arc
mode (which has no retain count effect).
// rdar://13514210
llvm-svn: 178592
|
| |
|
|
|
|
|
| |
specifier for an enumeration. Also fix a crash-on-invalid if a non-dependent
name specifier is used to declare an enum template.
llvm-svn: 178502
|
| |
|
|
|
|
| |
sugar for the _Atomic type specifier.
llvm-svn: 178210
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we are consuming the current token just to enter a new token stream, we push
the current token in the back of the stream so that we get it again.
Unfortunately this had the effect where if the current token is a code-completion one,
we would code-complete once during consuming it and another time after the stream ended.
Fix this by making sure that, in this case, ConsumeAnyToken() will consume a code-completion
token without invoking code-completion.
rdar://12842503
llvm-svn: 178199
|
| |
|
|
|
|
|
|
| |
<type_traits>.
Patch by me and Ryan Molden.
llvm-svn: 178111
|
| |
|
|
|
|
|
| |
using-declarations with names which look constructor-like are interpreted as
constructor names.
llvm-svn: 177957
|
| |
|
|
|
|
|
|
|
|
| |
behavioural
difference is that we no longer clean the token before emitting it. This fixes a bug where
clang hangs in the middle of crashing because the crash handler calls malloc from inside
a crash that happened inside of free.
llvm-svn: 177919
|
| |
|
|
| |
llvm-svn: 177705
|
| |
|
|
|
|
|
|
|
|
|
|
| |
picking up cleanups from earlier in the statement. Also fix a
crash-on-invalid where a reference to an invalid decl from an
enclosing scope was causing an expression to fail to build, but
only *after* a cleanup was registered from that statement,
causing an assertion downstream.
The crash-on-valid is rdar://13459289.
llvm-svn: 177692
|
| |
|
|
|
|
|
|
| |
I am not sure how much we can improve for
when a randon ObjC keyword is thrown into the
ivar decl. block. // rdar://6854840
llvm-svn: 177553
|
| |
|
|
|
|
|
| |
'}' is missing for the ivar declarations.
// rdar://6854840
llvm-svn: 177549
|
| |
|
|
|
|
| |
initializers.
llvm-svn: 177480
|
| |
|
|
|
|
|
|
|
| |
closing rbrace is missing in an ObjC class declaration.
Can do beter than this, but it involves addition of
overhead which will be present in correct code.
// rdar://6854840
llvm-svn: 177435
|
| |
|
|
|
|
| |
definition. Bump some related diagnostics from warning to extension in C++, since they're errors there. Add some missing checks for function specifiers on non-function declarations.
llvm-svn: 177335
|
| |
|
|
|
|
|
| |
therefore references to members should not be transformed into implicit uses of
'this'. Patch by Ismail Pazarbasi!
llvm-svn: 177134
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
template instantiation will still consider them to be definitions
if we instantiate the containing class before we get around
to parsing the friend.
This seems like a legitimate use of "late template parsed" to me,
but I'd appreciate it if someone responsible for the MS feature
would look over this.
This file already appears to access AST nodes directly, which
is arguably not kosher in the parser, but the performance of this
path matters enough that perpetuating the sin is justifiable.
Probably we ought to reconsider this policy for very simple
manipulations like this.
The reason this entire thing is necessary is that
function template instantiation plays some very gross games
in order to not associate an instantiated function template
with the class it came from unless it's a definition, and
the reason *that's* necessary is that the AST currently
cannot represent the instantiation history of individual
function template declarations, but instead tracks it in
common for the entire function template. That probably
prevents us from correctly reporting ill-formed calls to
ambiguously instantiated friend function templates.
rdar://12350696
llvm-svn: 177003
|
| |
|
|
| |
llvm-svn: 176704
|
| |
|
|
|
|
| |
Patch by Murat Bolat!
llvm-svn: 176686
|
| |
|
|
|
|
|
|
| |
Introduce a new AST Decl node "EmptyDecl" to model empty-declaration. Have attributes from attribute-declaration appertain
to the EmptyDecl node by creating the AST representations of these attributes and attach them to the EmptyDecl node so these
attributes can be sema checked just as attributes attached to "normal" declarations.
llvm-svn: 175900
|
| |
|
|
|
|
| |
in C++98.
llvm-svn: 175879
|
| |
|
|
|
|
| |
if it has declarators. We were missing the check for this in a couple of places.
llvm-svn: 175876
|
| |
|
|
| |
llvm-svn: 175875
|
| |
|
|
|
|
| |
and we used to assert if it did.
llvm-svn: 175866
|
| |
|
|
| |
llvm-svn: 175860
|
| |
|
|
|
|
|
|
|
|
|
| |
to control the check for the C 5.2.4.1 / C++ [implimits] restriction on nesting
levels for parentheses, brackets and braces.
Some code with heavy macro use exceeds the default limit of 256, but we don't
want to increase it generally to avoid stack overflow on stack-constrained
systems.
llvm-svn: 175855
|
| |
|
|
| |
llvm-svn: 175705
|
| |
|
|
|
|
| |
Post-commit CR feedback from Jordan Rose regarding r175594.
llvm-svn: 175679
|
| |
|
|
|
|
|
|
| |
which allows grouping parens in an abstract-pack-declarator. This was already
mostly implemented, but missed some cases. Add an ExtWarn for use of this
extension until CWG ratifies it.
llvm-svn: 175660
|
| |
|
|
|
|
|
| |
diagnose attributes on alias declarations, using directives, and attribute
declarations.
llvm-svn: 175649
|
| |
|
|
| |
llvm-svn: 175586
|
| |
|
|
|
|
|
|
| |
attributes yet, so just issue the appropriate diagnostics. Also generalize the
fixit for attributes-in-the-wrong-place code and reuse it here, if attributes
are placed after the access-specifier or 'virtual' in a base specifier.
llvm-svn: 175575
|
| |
|
|
|
|
|
| |
we don't do the scope checks otherwise we are going to hit assertion checks
since a label may not have been actually added.
llvm-svn: 175281
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MSVC accepts this:
class A {
A::A();
};
Clang accepts regular member functions with extra qualification as an MS
extension, but not constructors. This changes the parser to defer rejecting
qualified constructors so that the same Sema logic can apply to constructors as
regular member functions. This also improves the error message when MS
extensions are disabled (in my opinion). Before it was:
/Users/jason/Desktop/test.cpp:2:8: error: expected member name or ';' after declaration specifiers
A::A();
~~~~ ^
1 error generated.
After:
/Users/jason/Desktop/test.cpp:2:6: error: extra qualification on member 'A'
A::A();
~~~^
1 error generated.
Patch by Jason Haslam.
llvm-svn: 174980
|
| |
|
|
|
|
|
| |
Nearly all of these changes are one-to-one replacements; the few that
aren't have to do with custom identifier validation.
llvm-svn: 174768
|
| |
|
|
|
|
| |
in an unevaluated context.
llvm-svn: 174644
|
| |
|
|
|
|
| |
restrictions.
llvm-svn: 174601
|
| |
|
|
|
|
| |
-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
|