The warning isn't very useful when the function is an ObjC method.
rdar://problem/41561853
Differential Revision: https://reviews.llvm.org/D61147
llvm-svn: 359864
Because diagnostics and their notes are not connected at the API level,
if the error message for an overload is emitted, then the overload
candidates are completed - if a diagnostic is emitted during that work,
the notes related to overload candidates would be attached to the latter
diagnostic, not the original error. Sort of worse, if the latter
diagnostic was disabled, the notes are disabled.
Reviewers: rsmith
Differential Revision: https://reviews.llvm.org/D61357
llvm-svn: 359854
If an address_space attribute is defined in a macro, print the macro instead
when diagnosing a warning or error for incompatible pointers with different
address_spaces.
We allow this for all attributes (not just address_space), and for multiple
attributes declared in the same macro.
Differential Revision: https://reviews.llvm.org/D51329
llvm-svn: 359826
When the expression used to initialise 'this' has a pointer type,
check the address space of the pointee type instead of the pointer
type to decide whether an address space cast is required.
It is the pointee type that carries the address space qualifier.
Fixing PR41674.
Patch by kpet (Kevin Petit)!
Differential Revision: https://reviews.llvm.org/D61319
llvm-svn: 359798
Similarly to static variables in OpenCL, static class data
members should be deduced to __global addr space.
Differential Revision: https://reviews.llvm.org/D61304
llvm-svn: 359789
explicit function specialization with the MemberSpecializationInfo used
everywhere else.
Not NFC: the ad-hoc pattern tracking was not being serialized /
deserialized properly. That's fixed here.
llvm-svn: 359747
Summary:
This simplifies three checks for MS ABI, Win Itanium, or Win GNU to just
"is Windows".
The question remains, however, if this is really the correct thing to
do. We could, for example, only not consider inner classes to be
externally available if the outer class has a dllexport annotation.
However, I will leave that as future work.
Reviewers: hans, mstorsjo
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D61278
llvm-svn: 359507
us emitting the operand of __builtin_constant_p if it has side-effects.
Original commit message:
Fix interactions between __builtin_constant_p and constexpr to match
current trunk GCC.
GCC permits information from outside the operand of
__builtin_constant_p (but in the same constant evaluation context) to be
used within that operand; clang now does so too. A few other minor
deviations from GCC's behavior showed up in my testing and are also
fixed (matching GCC):
* Clang now supports nullptr_t as the argument type for
__builtin_constant_p
* Clang now returns true from __builtin_constant_p if called with a
null pointer
* Clang now returns true from __builtin_constant_p if called with an
integer cast to pointer type
llvm-svn: 359367
This provides intrinsics support for Memory Tagging Extension (MTE),
which was introduced with the Armv8.5-a architecture.
These intrinsics are available when __ARM_FEATURE_MEMORY_TAGGING is defined.
Each intrinsic is described in detail in the ACLE Q1 2019 documentation:
https://developer.arm.com/docs/101028/latest
Reviewed By: Tim Nortover, David Spickett
Differential Revision: https://reviews.llvm.org/D60485
llvm-svn: 359348
Normally, in MinGW mode, inline methods aren't dllexported.
However, in the case of a dllimported template instantiation,
the inline methods aren't instantiated locally, but referenced
from the instantiation. Therefore, those methods also need to
be dllexported, in the case of an instantiation.
GCC suffers from the same issue, reported at [1], but the issue
is still unresolved there.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89088
Differential Revision: https://reviews.llvm.org/D61176
llvm-svn: 359343
An explicit template instantiation declaration used to let
callers assume both outer and nested classes instantiations were
defined in a different translation unit.
If the instantiation is marked dllexport, only the outer class
is exported, but the caller will try to reference the instantiation
of both outer and inner classes.
This makes MinGW mode match both MSVC and Windows Itanium, by
having instantations only cover the outer class, and locally emitting
definitions of the nested classes. Windows Itanium was changed to
use this behavious in SVN r300804.
This deviates from what GCC does, but should be safe (and only
inflate the object file size a bit, but MSVC and Windows Itanium
modes do the same), and fixes cases where inner classes aren't
dllexported.
This fixes missing references in combination with dllexported/imported
template intantiations.
GCC suffers from the same issue, reported at [1], but the issue
is still unresolved there. The issue can probably be solved either
by making dllexport cover all nested classes as well, or this
way (matching MSVC).
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89087
Differential Revision: https://reviews.llvm.org/D61175
llvm-svn: 359342
counters.
According to the OpenMP 5.0, For any associated loop where the b or lb
expression is not loop invariant with respect to the outermost loop, the
var-outer that appears in the expression may not have a random access
iterator type.
llvm-svn: 359340
Contrary to MSVC, GCC/MinGW needs to have the dllexport attribute
on the template instantiation declaration, not on the definition.
Previously clang never marked explicit template instantiations as
dllexport in MinGW mode, if the instantiation had a previous
declaration, regardless of where the attribute was placed. This
makes Clang behave like GCC in this regard, and allows using the
same attribute form for both MinGW compilers.
This fixes PR40256.
Differential Revision: https://reviews.llvm.org/D61118
llvm-svn: 359285
internal linkage entities.
Such constructs are ill-formed by [temp.explicit]p13. We make a special
exception to permit an invalid construct used by libc++ in some build
modes: its <valarray> header declares some functions with the
internal_linkage attribute and then (meaninglessly) provides explicit
instantiation declarations for them. Luckily, Clang happens to
effectively ignore the explicit instantiation declaration when
generating code in this case, and this change codifies that behavior.
This reinstates part of r359048, reverted in r359076. (The libc++ issue
triggering the rollback has been addressed.)
llvm-svn: 359259
loop nests.
Added a checks that the initializer/condition expressions depend only
only of the single previous loop iteration variable.
llvm-svn: 359200
The change breaks libc++ with the follwing error:
In file included from valarray:4:
.../include/c++/v1/valarray:1062:60: error: explicit instantiation declaration of 'valarray<_Tp>' with internal linkage
_LIBCPP_EXTERN_TEMPLATE(_LIBCPP_FUNC_VIS valarray<size_t>::valarray(size_t))
^
.../include/c++/v1/valarray:1063:60: error: explicit instantiation declaration of '~valarray<_Tp>' with internal linkage
_LIBCPP_EXTERN_TEMPLATE(_LIBCPP_FUNC_VIS valarray<size_t>::~valarray())
llvm-svn: 359076
of an auto"
This commit changed the initializer expression passed into
initialization (stripping off an enclosing pair of parentheses or
braces) and subtly changing the meaning of programs, typically by
inserting bogus calls to copy constructors.
See the added testcase in test/SemaCXX/cxx1y-init-captures.cpp for an
example of the breakage.
llvm-svn: 359066
current trunk GCC.
GCC permits information from outside the operand of
__builtin_constant_p (but in the same constant evaluation context) to be
used within that operand; clang now does so too. A few other minor
deviations from GCC's behavior showed up in my testing and are also
fixed (matching GCC):
* Clang now supports nullptr_t as the argument type for
__builtin_constant_p
* Clang now returns true from __builtin_constant_p if called with a
null pointer
* Clang now returns true from __builtin_constant_p if called with an
integer cast to pointer type
llvm-svn: 359059
recursively captured.
Under ARC, a block variable is zero-initialized when it is recursively
captured by the block literal initializer.
rdar://problem/11022762
llvm-svn: 359049
Summary:
* Removed a member that was only used during construction.
* Use range-based for iteration when accessing the result of the search.
* Require an `ObjCMethodDecl` reference upon construction of an
* Constify.
Reviewers: rjmccall
Reviewed By: rjmccall
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D60850
llvm-svn: 358898
CWG 1691 changed the definition of the namespaces associated with a class
type or enumeration type.
For a class type, the associated namespaces are the innermost enclosing
namespaces of the associated classes. For an enumeration type, the associated
namespace is the innermost enclosing namespace of its declaration.
This also fixes CWG 1690 and CWG 1692.
Differential Revision: https://reviews.llvm.org/D60573
Reviewed By: rjmccall, rsmith
llvm-svn: 358882
Clang emits a warning when using a pure specifier =0 in a function definition
at class scope (a MS-specific construct), when using -fms-extensions.
However, to detect this, it was using FD->isCanonicalDecl() on function
declaration, which was also detecting out-of-class definition of member
functions of class templates. Fix this by using !FD->isOutOfLine() instead.
Fixes PR21334.
Differential Revision: https://reviews.llvm.org/D29707
Reviewed By: riccibruno
Reviewers: rnk, riccibruno
Patch By: Rudy Pons
llvm-svn: 358849
The code is/was already correct for the case where a parameter is a
parameter of its enclosing lexical DeclContext (functions and classes).
But for other templates (alias and variable templates) they don't create
their own scope to be members of - in those cases, they parameter should
be considered visible if any definition of the lexical decl context is
visible.
[this should cleanup the failure on the libstdc++ modules buildbot]
[this doesn't actually fix the variable template case for a
secondary/compounding reason (its lexical decl context is incorrectly
considered to be the translation unit)]
Test covers all 4 kinds of templates with default args, including a
regression test for the still broken variable template case.
Reviewers: rsmith
Differential Revision: https://reviews.llvm.org/D60892
llvm-svn: 358795
Summary: The requires directive containing target related clauses must appear before any target region in the compilation unit.
Reviewers: ABataev, AlexEichenberger, caomhin
Reviewed By: ABataev
Subscribers: guansong, jfb, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60875
llvm-svn: 358709
global module fragment.
We know that the declaration in question should have been introduced by
a '#include', so try to figure out which one and suggest it. Don't
suggest importing the global module fragment itself!
llvm-svn: 358631
retaining block and all of the enclosing blocks are non-escaping.
If the block implicitly retaining self doesn't escape, there is no risk
of creating retain cycles, so clang shouldn't diagnose it and force
users to add self-> to silence the diagnostic.
Also, fix a bug where clang was failing to diagnose an implicitly
retained self inside a c++ lambda nested inside a block.
rdar://problem/25059955
Differential Revision: https://reviews.llvm.org/D60736
llvm-svn: 358624
and the global and private module fragment.
For now, the private module fragment introducer is ignored, but use of
the global module fragment introducer should be properly enforced.
llvm-svn: 358353
We want to make objc_nonlazy_class apply to implementations, but ran into this.
There doesn't seem to be any reason that this isn't supported.
Differential revision: https://reviews.llvm.org/D60542
llvm-svn: 358200
Summary:
As was already stated in a previous comment, the parameter isn't
necessarily referring to one of the DeclContext's parameter. We
should check the index is within the range to avoid out-of-boundary
access.
Reviewers: gribozavr, rsmith, lebedev.ri
Reviewed By: gribozavr, rsmith
Subscribers: lebedev.ri, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60055
Patch by Violet.
llvm-svn: 358134
Mandeep Singh Grang