of class fails to map class static variable.
If the global variable is captured and it has several redeclarations,
sometimes it may lead to a compiler crash. Patch fixes this by working
only with canonical declarations.
llvm-svn: 311479
C++14 added user-defined literal support for complex numbers so that you
can write something like "complex<double> val = 2i". However, there is
an existing GNU extension supporting this syntax and interpreting the
result as a _Complex type.
This changes parsing so that such literals are interpreted in terms of
C++14's operators if an overload is present but otherwise falls back to
the original GNU extension.
(We now have more robust diagnostics for implicit conversions so the
libc++ test that caused the original revert still passes).
llvm-svn: 310478
Converting a _Complex type to a real one simply discards the imaginary part.
This can easily lead to loss of information so for safety (and GCC
compatibility) this patch disallows that when the conversion would be implicit.
The one exception is bool, which actually compares both real and imaginary
parts and so is safe.
llvm-svn: 310427
Arguments, passed to the outlined function, must have correct address
space info for proper Debug info support. Patch sets global address
space for arguments that are mapped and passed by reference.
Also, cuda-gdb does not handle reference types correctly, so reference
arguments are represented as pointers.
llvm-svn: 310387
Arguments, passed to the outlined function, must have correct address
space info for proper Debug info support. Patch sets global address
space for arguments that are mapped and passed by reference.
Also, cuda-gdb does not handle reference types correctly, so reference
arguments are represented as pointers.
llvm-svn: 310377
Arguments, passed to the outlined function, must have correct address
space info for proper Debug info support. Patch sets global address
space for arguments that are mapped and passed by reference.
Also, cuda-gdb does not handle reference types correctly, so reference
arguments are represented as pointers.
llvm-svn: 310360
Arguments, passed to the outlined function, must have correct address
space info for proper Debug info support. Patch sets global address
space for arguments that are mapped and passed by reference.
Also, cuda-gdb does not handle reference types correctly, so reference
arguments are represented as pointers.
llvm-svn: 310104
Summary:
The mis-compile is triggered by internal code, but I haven't reduced it to a small piece of code. Add a FIXME here, since a decent fix doesn't seem to be trivial.
The decent fix can be changing Decl::Init to PointerUnion<Stmt *, EvaluatedStmt *, ParamVarDecl *>, and make setUninstantiatedDefaultArg take a ParamVarDecl *, which contains the Expr * as the default argument. This way, getTemplateInstantiationArgs can take that ParamVarDecl and do the right thing.
Reviewers: rsmith
Subscribers: sanjoy, cfe-commits
Differential Revision: https://reviews.llvm.org/D36253
llvm-svn: 309908
r282968 introduced a regression due to the lack of proper testing.
Re-add lax conversion support between non ext vectors for compound
assignments and add a test for that.
rdar://problem/28639467
llvm-svn: 309722
devirtualized.
The code to detect devirtualized calls is already in IRGen, so move the
code to lib/AST and make it a shared utility between Sema and IRGen.
This commit fixes a linkage error I was seeing when compiling the
following code:
$ cat test1.cpp
struct Base {
virtual void operator()() {}
};
template<class T>
struct Derived final : Base {
void operator()() override {}
};
Derived<int> *d;
int main() {
if (d)
(*d)();
return 0;
}
rdar://problem/33195657
Differential Revision: https://reviews.llvm.org/D34301
llvm-svn: 307883
requirements in protocol/class/category declarations
The unguarded availability warnings in the protocol requirements of a protocol
/class/category declaration can be avoided. This matches the behaviour of
Swift's diagnostics. The warnings for deprecated/unavailable protocols are
preserved.
rdar://33156429
Differential Revision: https://reviews.llvm.org/D35061
llvm-svn: 307368
Bitwise complement applied to vector of floats described with
attribute `ext_vector_type` is not diagnosed as error. Attempt to
compile such construct causes assertion violation in Instruction.cpp.
With this change the complement is treated similar to the case of
vector type described with attribute `vector_size`.
Differential Revision: https://reviews.llvm.org/D33732
llvm-svn: 304963
template is valid with or without it (with different meanings).
If we see "dependent.x<...", and what follows the '<' is a valid expression,
we must parse the '<' as a comparison rather than a template angle bracket.
When we later come to instantiate, if we find that the LHS of the '<' actually
names an overload set containing function templates, produce a diagnostic
suggesting that the 'template' keyword was missed rather than producing a
mysterious diagnostic saying that the function must be called (and pointing
at what looks to already be a function call!).
llvm-svn: 304852
Summary:
This is the fix for patch https://reviews.llvm.org/D33353
@uweigand, could you please verify that everything will be good on SystemZ?
I added triple spir-unknown-unknown.
Thank you in advance!
Reviewers: uweigand
Reviewed By: uweigand
Subscribers: yaxunl, cfe-commits, bader, Anastasia, uweigand
Differential Revision: https://reviews.llvm.org/D33648
llvm-svn: 304191
This is an initial commit to allow using it with constant expressions, a follow-up commit will enable full support for it in ObjC methods.
llvm-svn: 303712
C++14 added user-defined literal support for complex numbers so that you can
write something like "complex<double> val = 2i". However, there is an existing
GNU extension supporting this syntax and interpreting the result as a _Complex
type.
This changes parsing so that such literals are interpreted in terms of C++14's
operators if an overload is present but otherwise falls back to the original
GNU extension.
llvm-svn: 303694
This fix UBSAN bots after r302935. Storing non-defined values in enum is
undefined behavior.
Other places, where "if (ScalarCast != CK_Invalid)" is used, never get to the
"if" with CK_Invalid. tryGCCVectorConvertAndSplat can get to the "if" with
CK_Invalid and it looks like expected case. So we have to use something other
than CK_Invalid, e.g. CK_NoOp.
llvm-svn: 303121
This patch teaches clang to perform implicit scalar to vector conversions
when one of the operands of a binary vector expression is a scalar which
can be converted to the element type of the vector without truncation
following GCC's implementation.
If the (constant) scalar is can be casted safely, it is implicitly casted to the
vector elements type and splatted to produce a vector of the same type.
Contributions from: Petar Jovanovic
Reviewers: bruno, vkalintiris
Differential Revision: https://reviews.llvm.org/D25866
llvm-svn: 302935
In C typos in arguments in a call of an overloadable function lead
to a failure of construction of CallExpr and following recovery does
not handle created delayed typos. This causes an assertion fail in
Sema::~Sema since Sema::DelayedTypos remains not empty.
The patch fixes that behavior by handling a call with arguments
having dependant types in the way that C++ does.
Differential Revision: https://reviews.llvm.org/D31764
Patch by Dmitry Borisenkov!
llvm-svn: 302435
Summary:
When the function is compiled with soft-float or on CPU with no FPU, we
don't need to diagnose for a call from an ISR to a regular function.
Reviewers: jroelofs, eli.friedman
Reviewed By: jroelofs
Subscribers: aemerson, rengolin, javed.absar, cfe-commits
Differential Revision: https://reviews.llvm.org/D32918
llvm-svn: 302274
blocks and lambdas
Prior to this commit Clang emitted the old "partial availability" warning for
expressions that referred to declarations that were not yet introduced in
blocks and lambdas that were not in a function/method. This commit ensures that
top-level blocks and lambdas use the new unguarded availability checks.
rdar://31835952
llvm-svn: 301409
This commit teaches Clang to recognize editor placeholders that are produced
when an IDE like Xcode inserts a code-completion result that includes a
placeholder. Now when the lexer sees a placeholder token, it emits an
'editor placeholder in source file' error and creates an identifier token
that represents the placeholder. The parser/sema can now recognize the
placeholders and can suppress the diagnostics related to the placeholders. This
ensures that live issues in an IDE like Xcode won't get spurious diagnostics
related to placeholders.
This commit also adds a new compiler option named '-fallow-editor-placeholders'
that silences the 'editor placeholder in source file' error. This is useful
for an IDE like Xcode as we don't want to display those errors in live issues.
rdar://31581400
Differential Revision: https://reviews.llvm.org/D32081
llvm-svn: 300667
This improves some error messages which would otherwise refer to
ext_vector_type types in contexts where there are no such types.
Factored out from D25866 at reviewer's request.
Reviewers: bruno
Differential Revision: https://reviews.llvm.org/D31667
llvm-svn: 299641
Summary:
I saw the same changes in the following review: https://reviews.llvm.org/D17438
I don't know in that way I could determine that atomic variable was initialized by macro ATOMIC_VAR_INIT. Anyway I added check that atomic variables can be initialize only in global scope.
I think that we can discuss this change.
Reviewers: Anastasia, cfe-commits
Reviewed By: Anastasia
Subscribers: bader, yaxunl
Differential Revision: https://reviews.llvm.org/D30643
llvm-svn: 299537
- also replace direct equality checks against the ConstantEvaluated enumerator with isConstantEvaluted(), in anticipation of adding finer granularity to the various ConstantEvaluated contexts and reinstating certain restrictions on where lambda expressions can occur in C++17.
- update the clang tablegen backend that uses these Enumerators, and add the relevant scope where needed.
llvm-svn: 299316
an ObjC object pointer
When ARC is enabled in Objective-C++, comparisons between a pointer and
Objective-C object pointer typically result in errors like this:
"invalid operands to a binary expression". This error message can be quite
confusing as it doesn't provide a solution to the problem, unlike the non-C++
diagnostic: "implicit conversion of Objective-C pointer type 'id' to C pointer
type 'void *' requires a bridged cast" (it also provides fix-its). This commit
forces comparisons between pointers and Objective-C object pointers in ARC to
use the Objective-C semantic rules to ensure that a better diagnostic is
reported.
rdar://31103857
Differential Revision: https://reviews.llvm.org/D31177
llvm-svn: 299080
Summary: clang should produce the same errors Objective-C classes that cannot be assigned to weak pointers under both -fobjc-arc and -fobjc-weak. Check for ObjCWeak along with ObjCAutoRefCount when analyzing pointer conversions. Add an -fobjc-weak pass to the existing arc-unavailable-for-weakref test cases to verify the behavior is the same.
Reviewers: rsmith, doug.gregor, rjmccall
Reviewed By: rjmccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D31006
llvm-svn: 299014
Summary: -Warc-repeated-use-of-weak should produce the same warnings with -fobjc-weak as it does with -objc-arc. Also check for ObjCWeak along with ObjCAutoRefCount when recording the use of an evaluated weak variable. Add a -fobjc-weak run to the existing arc-repeated-weak test case and adapt it slightly to work in both modes.
Reviewers: rsmith, doug.gregor, jordan_rose, rjmccall
Reviewed By: rjmccall
Subscribers: arphaman, rjmccall, cfe-commits
Differential Revision: https://reviews.llvm.org/D31005
llvm-svn: 299011
