It's better not to rely on the diagnostics engine to pretty print the
argument to decltype. Instead, exercise the functionality in
DeclPrinterTest.
llvm-svn: 239197
We would crash in the DeclPrinter trying to pretty-print the
static_assert message. C++1z-style assertions don't have a message so
we would crash.
This fixes PR23756.
llvm-svn: 239170
The MSVC 2013 and 2015 implementation of std::atomic is specialized for
pointer types. The member functions are implemented using a static_cast
from void-ptr to function-ptr which is not allowed in the standard.
Permit this conversion if -fms-compatibility is present.
This fixes PR23733.
llvm-svn: 238877
this fixes http://llvm.org/PR17424
fillAttributedTypeLoc() function is only called with AttributeLists of either
DeclarationChunk (which is used for each type in a declarator being parsed) or
DeclSpec (which captures information about declaration specifiers).
As C++11 attributes actually appertain to declarators, they are moved straight
to the declarator’s attr list in distributeFunctionTypeAttrFromDeclSpec()
function.
'Put them wherever you like' semantics is not supported for C++11 attributes
(but is allowed for GNU attributes, for example). So when we meet an attribute
while parsing the declaration, we cannot be sure if it appertains to either
DeclarationChunk or DeclSpec.
This investigation correlates with the history of changes of SemaType.cpp:
• Asserts in fillAttributedTypeLoc() were added on 3 Mar 2011 in r126986
(http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-
20110228/039638.html);
• Distributing C++11 attrs to the declarator was added on 14 Jan 2013
in r172504 (http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-
20130114/071830.html).
Considering all written above I changed asserts in fillAttributedTypeLoc()
to nullptr checks.
This fixes PR17424 and related assertion on
[[gnu::fastcall]] void __stdcall foo();
Author: Alexey Frolov
Differential Revision: http://reviews.llvm.org/D9288
llvm-svn: 238550
When checking if a function is noreturn, consider a codepath to be noreturn if
the path destroys a class and the class destructor, base class destructors, or
member field destructors are marked noreturn.
Differential Revision: http://reviews.llvm.org/D9454
llvm-svn: 238382
Note: __declspec is also temporarily enabled when compiling for a CUDA target because there are implementation details relying on __declspec(property) support currently. When those details change, __declspec should be disabled for CUDA targets.
llvm-svn: 238238
Emit warning when operand to `delete` is allocated with `new[]` or
operand to `delete[]` is allocated with `new`.
rev 2 update:
`getNewExprFromInitListOrExpr` should return `dyn_cast_or_null`
instead of `dyn_cast`, since `E` might be null.
Reviewers: rtrieu, jordan_rose, rsmith
Subscribers: majnemer, cfe-commits
Differential Revision: http://reviews.llvm.org/D4661
llvm-svn: 237608
The error has the form ... 'int' ... 'const int' ... dropped qualifiers. At
first glance, it appears that the const qualifier is added. Reverse the types
so that the second type is less qualified than the first.
llvm-svn: 237482
This reverts commit 742dc9b6c9686ab52860b7da39c3a126d8a97fbc.
This is generating multiple segfaults in our internal builds.
Test case coming up shortly.
llvm-svn: 237391
Emit warning when operand to `delete` is allocated with `new[]` or
operand to `delete[]` is allocated with `new`.
Reviewers: rtrieu, jordan_rose, rsmith
Subscribers: majnemer, cfe-commits
Differential Revision: http://reviews.llvm.org/D4661
llvm-svn: 237368
A LambdaCapture does not have sufficient information
to correctly determine whether it is an init-capture or not.
Doing so requires knowledge held in the LambdaExpr itself.
It the case of a nested capture of an init-capture it is not
sufficient to check (as LambdaCapture::isInitCapture did)
whether the associated VarDecl was from an init-capture.
This patch moves isInitCapture to LambdaExpr and updates
Capture->isInitCapture() to Lambda->isInitCapture(Capture).
llvm-svn: 236760
This is needed to prevent a TypoExpr from being corrected to a variable
when the TypoExpr is a subexpression of that variable's initializer.
Also exclude more keywords from the correction candidate pool when the
subsequent token is .* or ->* since keywords like "new" or "return"
aren't valid on the left side of those operators.
Fixes PR23140.
llvm-svn: 236519
The LHS was already being corrected before being set to ExprError when
the RHS is invalid, but when it was present the middle of a ternary
expression would be dropped in the error paths.
Fixes PR23350.
llvm-svn: 236347
-Wpessimizing-move warns when a call to std::move would prevent copy elision
if the argument was not wrapped in a call. This happens when moving a local
variable in a return statement when the variable is the same type as the
return type or using a move to create a new object from a temporary object.
-Wredundant-move warns when an implicit move would already be made, so the
std::move call is not needed, such as when moving a local variable in a return
that is different from the return type.
Differential Revision: http://reviews.llvm.org/D7633
llvm-svn: 236075
Previously we'd try to perform checks on the captures from the middle of
parsing the lambda's body, at the point where we detected that a variable
needed to be captured. This was wrong in a number of subtle ways. In
PR23334, we couldn't correctly handle the list of potential odr-uses
resulting from the capture, and our attempt to recover from that resulted
in a use-after-free.
We now defer building the initialization expression until we leave the lambda
body and return to the enclosing context, where the initialization does the
right thing. This patch only covers lambda-expressions, but we should apply
the same change to blocks and captured statements too.
llvm-svn: 235921
We could probably make this work if we cared enough. However, we are
far outside any language rules at this point.
This fixes PR21834.
llvm-svn: 235818
For example, a function taking a parameter with internal linkage will
itself have internal linkage since it cannot be called outside the
translation unit.
Differential Revision: http://reviews.llvm.org/D9182
llvm-svn: 235471
(For example needed to parse system header inputscope.h, which first has
an extern "C" selectany IID and then later an extern "C" declaration of that
same IID.)
llvm-svn: 235174
r235046 turned "extern __declspec(selectany) int a;" from a declaration into
a definition to fix PR23242 (required for compatibility with mc.exe output).
However, this broke parsing Windows headers: A d3d11 headers contain something
like
struct SomeStruct {};
extern const __declspec(selectany) SomeStruct some_struct;
This is now a definition, and const objects either need an explicit default
ctor or an initializer so this errors out with
d3d11.h(1065,48) :
error: default initialization of an object of const type
'const CD3D11_DEFAULT' without a user-provided default constructor
(cl.exe just doesn't implement this rule, independent of selectany.)
To work around this, weaken this error into a warning for selectany decls
in microsoft mode, and recover with zero-initialization.
Doing this is a bit hairy since it adds a fixit on an error emitted
by InitializationSequence – this means it needs to build a correct AST, which
in turn means InitializationSequence::Failed() cannot return true when this
fixit is applied. As a workaround, the patch adds a fixit member to
InitializationSequence, and InitializationSequence::Perform() prints the
diagnostic if the fixit member is set right after its call to Diagnose.
That function is usually called when InitializationSequences are used –
InitListChecker::PerformEmptyInit() doesn't call it, but the InitListChecker
case never performs default-initialization, so this is technically OK.
This is the alternative, original fix for PR20208 that got reviewed in the
thread "[patch] Improve diagnostic on default-initializing const variables
(PR20208)". This change basically reverts r213725, adds the original fix for
PR20208, and makes the error a warning in Microsoft mode.
llvm-svn: 235166
-Wrange-loop-analysis is a subgroup of -Wloop-analysis and will warn when
a range-based for-loop makes copies of the elements in the range. If possible,
suggest the proper type to prevent copies, or the non-reference to help
distinguish copy versus non-copy forms. Existing warnings in -Wloop-analysis
are moved to -Wfor-loop-analysis, also a subgroup of -Wloop-analysis.
Differential Revision: http://reviews.llvm.org/D4169
llvm-svn: 234804
Previously, many error messages would simply be "read-only variable is not
assignable" This change provides more information about why the variable is
not assignable, as well as note to where the const is located.
Differential Revision: http://reviews.llvm.org/D4479
llvm-svn: 234677
Take advantage of the delayed typo no longer being eagerly corrected to
a keyword to filter out keyword corrections (and other things like
unresolved & overloaded expressions, which have placeholder types) when
correcting typos inside of a decltype().
llvm-svn: 234623
Given something like 'int({}, 1)', we would try to emit a diagnostic
regarding the excess element in the scalar initializer. However, we
assumed that the initializer list had an element in it.
llvm-svn: 234565
A [*] is only allowed in a declaration for a function, not in its
definition. We didn't correctly recurse on reference types while
looking for it, causing us to crash in CodeGen instead of rejecting it.
llvm-svn: 234528
The previous implementation would copy the attribute from the class to
functions that have the class as their return type when the functions
are first declared. This proved to have two flaws:
1) if the class is forward-declared without the attribute and a
function or method with the class as a its return type is declared,
and afterward the class is defined with warn_unused_result, the
function or method would never inherit the attribute, and
2) the check simply failed for functions and methods that are part of
a template instantiation, regardless of whether the class with
warn_unused_result is part of a specific instantiation or part of
the template itself (presumably because those function/method
declaration does not hit the same code path as a non-template one
and so never inherits the attribute).
The new approach is to instead modify the two places where a function or
method call is checked for the warn_unused_result attribute on the decl
by extending the checks to also look for the attribute on the decl's
return type.
Additionally, the check for return types that have the warn_unused_result
now excludes pointers and references to such types, as such return types do
not necessarily imply a transfer of ownership for the underlying object
being referred to by the return value. This does not change the behavior
of functions that are directly given the warn_unused_result attribute.
llvm-svn: 234526
A dependent alignment attribute (like __attribute__((aligned(...))) or
__declspec(align(...))) on a non-dependent typedef or using declaration
poses a considerable challenge: the type is _not_ dependent, the size
_may_ be dependent if the type is used as an array type, the alignment
_is_ dependent.
It is reasonable for a compiler to be able to query the size and
alignment of a complete type. Let's help that become an invariant.
This fixes PR22042.
Differential Revision: http://reviews.llvm.org/D8693
llvm-svn: 234280
StmtPrinter assumed that the first template arg was the pack and
attempted to iterate it. However, the GNU extension (which is really
just N3599), has two template arguments. In this case, the second
argument is the pack containing the string contents.
Handle this by desugaring the call to the explicit operator.
For example:
"qux" _zombocom will be shown as
operator "" _zombocom<char, 'q', 'u', 'x'>() in diagnostics and AST
dumps.
N.B. It is actually impossible to render the arguments back to the
source form without storing more information in the AST. For example,
we cannot tell if the user wrote u8"qux" or "qux". We also lose
fidelity when it comes to non-char types for this exact reason (e.g. it
is hard to render a list of wchar_t back to something that can be
printed to the screen even if you don't have to consider surrogate
pairs).
This fixes PR23120.
llvm-svn: 234110
Update the test cases to pass when lambda call operators use thiscall.
Update the lambda-to-block conversion operator to use the default free
function calling convention instead of the call operator's convention.
This reverts commit r233082 and re-instates r233023.
llvm-svn: 233835
ExpandBuiltinMacro would strip the identifier and downstream users crash
when they encounter an identifier token with nullptr identifier info.
Found by afl-fuzz.
llvm-svn: 233497
David Majnemer