| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
(FixIts yet to be tested.)
llvm-svn: 184503
|
|
|
|
|
|
| |
an asm label.
llvm-svn: 184069
|
|
|
|
|
|
| |
macro defined in a system header. glibc uses it in macros, apparently.
llvm-svn: 184005
|
|
|
|
|
|
|
|
|
| |
- 'register' storage class
- dynamic exception specifications
Only the former check is enabled by default for now (the latter might be quite noisy).
llvm-svn: 183881
|
|
|
|
|
|
| |
Differential Revision: http://llvm-reviews.chandlerc.com/D586
llvm-svn: 183609
|
|
|
|
|
|
|
|
| |
places which weren't setting it up properly. This allows us to get the right
cv-qualifiers for 'this' when it appears outside a method body in a class
template.
llvm-svn: 183483
|
|
|
|
|
|
|
|
|
|
| |
pointer type qualifiers. This patch also fixes the correlated __ptr32 and __ptr64 pointer qualifiers so that they are truly type attributes instead of declaration attributes.
For more information about __sptr and __uptr, see MSDN: http://msdn.microsoft.com/en-us/library/aa983399.aspx
Patch reviewed by Richard Smith.
llvm-svn: 182535
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The most common (non-buggy) case are where such objects are used as
return expressions in bool-returning functions or as boolean function
arguments. In those cases I've used (& added if necessary) a named
function to provide the equivalent (or sometimes negative, depending on
convenient wording) test.
DiagnosticBuilder kept its implicit conversion operator owing to the
prevalent use of it in return statements.
One bug was found in ExprConstant.cpp involving a comparison of two
PointerUnions (PointerUnion did not previously have an operator==, so
instead both operands were converted to bool & then compared). A test
is included in test/SemaCXX/constant-expression-cxx1y.cpp for the fix
(adding operator== to PointerUnion in LLVM).
llvm-svn: 181869
|
|
|
|
|
|
| |
hookup. For more information about safebuffers, see MSDN: http://msdn.microsoft.com/en-us/library/dd778695(v=vs.110).aspx
llvm-svn: 181123
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
arguments as expressions.
This change partly addresses a heinous problem we have with the
parsing of attribute arguments that are a lone identifier. Previously,
we would end up parsing the 'align' attribute of this as an expression
"(Align)":
template<unsigned Size, unsigned Align>
class my_aligned_storage
{
__attribute__((align((Align)))) char storage[Size];
};
while this would parse as a "parameter name" 'Align':
template<unsigned Size, unsigned Align>
class my_aligned_storage
{
__attribute__((align(Align))) char storage[Size];
};
The code that handles the alignment attribute would completely ignore
the parameter name, so the while the first of these would do what's
expected, the second would silently be equivalent to
template<unsigned Size, unsigned Align>
class my_aligned_storage
{
__attribute__((align)) char storage[Size];
};
i.e., use the maximal alignment rather than the specified alignment.
Address this by sniffing the "Args" provided in the TableGen
description of attributes. If the first argument is "obviously"
something that should be treated as an expression (rather than an
identifier to be matched later), parse it as an expression.
Fixes <rdar://problem/13700933>.
llvm-svn: 180973
|
|
|
|
| |
llvm-svn: 180972
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
arguments as expressions.
This change partly addresses a heinous problem we have with the
parsing of attribute arguments that are a lone identifier. Previously,
we would end up parsing the 'align' attribute of this as an expression
"(Align)":
template<unsigned Size, unsigned Align>
class my_aligned_storage
{
__attribute__((align((Align)))) char storage[Size];
};
while this would parse as a "parameter name" 'Align':
template<unsigned Size, unsigned Align>
class my_aligned_storage
{
__attribute__((align(Align))) char storage[Size];
};
The code that handles the alignment attribute would completely ignore
the parameter name, so the while the first of these would do what's
expected, the second would silently be equivalent to
template<unsigned Size, unsigned Align>
class my_aligned_storage
{
__attribute__((align)) char storage[Size];
};
i.e., use the maximal alignment rather than the specified alignment.
Address this by sniffing the "Args" provided in the TableGen
description of attributes. If the first argument is "obviously"
something that should be treated as an expression (rather than an
identifier to be matched later), parse it as an expression.
Fixes <rdar://problem/13700933>.
llvm-svn: 180970
|
|
|
|
| |
llvm-svn: 180822
|
|
|
|
|
|
| |
Patch by Robert Wilhelm.
llvm-svn: 180682
|
|
|
|
| |
llvm-svn: 180610
|
|
|
|
|
|
|
| |
C++98 mode. This improves on the previous diagnostic message of:
error: expected identifier or '{'
llvm-svn: 180076
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Fixes PR13580. Patch by Serge Pavlov!
llvm-svn: 179743
|
|
|
|
|
|
| |
Serve Pavlov!
llvm-svn: 179603
|
|
|
|
|
|
|
|
| |
references thereto.
Patch by Tong Shen!
llvm-svn: 179585
|
|
|
|
|
|
| |
semantics as __thread for now.
llvm-svn: 179424
|
|
|
|
|
|
| |
a non-variable iteration declaration.
llvm-svn: 179053
|
|
|
|
|
|
| |
C11 6.7.2.1p1).
llvm-svn: 178632
|
|
|
|
| |
llvm-svn: 178631
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
therefore references to members should not be transformed into implicit uses of
'this'. Patch by Ismail Pazarbasi!
llvm-svn: 177134
|
|
|
|
| |
llvm-svn: 176704
|
|
|
|
|
|
| |
Patch by Murat Bolat!
llvm-svn: 176686
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
OpenCL restrictions (OpenCL 1.2 spec 6.9)
llvm-svn: 172973
|
|
|
|
| |
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
|