const-qualified parameter type and the defined with a non-const-qualified
parameter type, the parameter is not const inside its body. Ensure that
the type we use when instantiating the body is the right one. Patch by
suyog sarda!
This is still rather unsatisfactory; it seems like it might be better to
instantiate at least the function parameters, and maybe the complete function
declaration, when we instantiate the definition for such a member function
(instead of reusing the declaration from inside the instantiated class
definition).
llvm-svn: 203741
that implicitly converts to 'bool' (such as pointers, and the first operand of
?:). Clean up issues found by this. Patch by Stephan Tolksdorf!
llvm-svn: 203735
Someone could write:
if (0) {
__c11_atomic_load(ptr, memory_order_release);
}
or the equivalent, which is perfectly valid, so we shouldn't outright reject
invalid orderings on purely static grounds.
rdar://problem/16242991
llvm-svn: 203564
This is a conservative check, because it's valid for the expression to be
non-constant, and in cases like that we just don't know whether it's valid.
rdar://problem/16242991
llvm-svn: 203561
if the type's declaration was previously instantiated in an unimported module.
(For an imported type definition, this already worked, because the source
location is set to the location of the definition, but for locally-instantiated
type definitions, it did not.)
llvm-svn: 203425
Clang might crash while reading the precompiled headers if
we don't initialize the AttrEnumOperandLoc properly.
This commit fixes the combination of string attribute
operand and enum operand. Besides, this commit also adds
several assertions to avoid unexpected operand kind.
llvm-svn: 203416
This is a reapplication of r203236 with modifications to the definition of attrs() and following the new style guidelines on auto usage.
llvm-svn: 203362
getTypeSize (which rounds up sizes) in order to issue diagnostics
when casting to mismatched vector sizes; instead of crashing in IRGen.
// rdar:// 16196902. Reviewed offline by John McCall.
llvm-svn: 203175
Note that for backwards compatibility, an unnamed capability will default to being a "mutex." This allows the deprecated lockable attribute to continue to function.
llvm-svn: 203012
Summary:
The MSVC ABI appears to mangle the lexical scope into the names of
statics. Specifically, a counter is incremented whenever a scope is
entered where things can be declared in such a way that an ambiguity can
arise. For example, a class scope inside of a class scope doesn't do
anything interesting because the nested class cannot collide with
another nested class.
There are problems with this scheme:
- It is unreliable. The counter is only incremented when a previously
never encountered scope is entered. There are cases where this will
cause ambiguity amongst declarations that have the same name where one
was introduced in a deep scope while the other was introduced right
after in the previous lexical scope.
- It is wasteful. Statements like: {{{{{{{ static int foo = a; }}}}}}}
will make the mangling of "foo" larger than it need be because the
scope counter has been incremented many times.
Because of these problems, and practical implementation concerns. We
choose not to implement this scheme if the local static or local type
isn't visible. The mangling of these declarations will look very
similar but the numbering will make far more sense, this scheme is
lifted from the Itanium ABI implementation.
Reviewers: rsmith, doug.gregor, rnk, eli.friedman, cdavis5x
Reviewed By: rnk
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2953
llvm-svn: 202951
Per more discussion, 'objc_protocol_requires_explicit_implementation' is
refinement that it mainly adds that requirement that a protocol must be
explicitly satisfied at the moment the first class in the class hierarchy
conforms to it. Any subclasses that also conform to that protocol,
either directly or via conforming to a protocol that inherits that protocol,
do not need to re-implement that protocol.
Doing this requires first doing a pass on the super class hierarchy,
gathering the set of protocols conformed to by the super classes,
and then culling those out when determining conformance. This
two-pass algorithm could be generalized for all protocol checking,
and could possibly be a performance win in some cases. For now
we restrict this change to protocols with this attribute to isolate
the change in logic (especially as the design continues to evolve).
This change needs to be adjusted for properties as well; this
only impacts methods right now.
llvm-svn: 202948
const char *format = "%s";
std::experimental::string_view view = "foo";
printf(format, view);
In this case, not only warn about a class type being used here, but also suggest that calling c_str() might be a good idea.
llvm-svn: 202461
or virtual functions, but permit that error to be downgraded to
a warning (with -Wno-error=incompatible-ms-struct), and officially
support this kind of dual, ABI-mixing layout.
The basic problem here is that projects which use ms_struct are often
not very circumspect about what types they annotate; for example,
some projects enable the pragma in a prefix header and then only
selectively disable it around system header inclusions. They may
only care about binary compatibility with MSVC for a subset of
those structs, but that doesn't mean they have no binary
compatibility concerns at all for the rest; thus we are essentially
forced into supporting this hybrid ABI. But it's reasonable for
us to at least point out the places where we're not making
any guarantees.
The original diagnostic was for dynamic classes, i.e. those with
virtual functions or virtual bases; I've extended it to include
all classes with bases, because we are not actually making any
attempt to duplicate MSVC's base subobject layout in ms_struct
(and it is indeed quite different from Itanium, even for
non-virtual bases).
rdar://16178895
llvm-svn: 202427
null comparison when the pointer is known to be non-null.
This catches the array to pointer decay, function to pointer decay and
address of variables. This does not catch address of function since this
has been previously used to silence a warning.
Pointer to bool conversion is under -Wbool-conversion.
Pointer to null comparison is under -Wtautological-pointer-compare, a sub-group
of -Wtautological-compare.
void foo() {
int arr[5];
int x;
// warn on these conditionals
if (foo);
if (arr);
if (&x);
if (foo == null);
if (arr == null);
if (&x == null);
if (&foo); // no warning
}
llvm-svn: 202216
The warnings fall into three groups.
1) Using an absolute value function of the wrong type, for instance, using the
int absolute value function when the argument is a floating point type.
2) Using the improper sized absolute value function, for instance, using abs
when the argument is a long long. llabs should be used instead.
From these two cases, an implicit conversion will occur which may cause
unexpected behavior. Where possible, suggest the proper absolute value
function to use, and which header to include if the function is not available.
3) Taking the absolute value of an unsigned value. In addition to this warning,
suggest to remove the function call. This usually indicates a logic error
since the programmer assumed negative values would have been possible.
llvm-svn: 202211
The __forceinline keyword's semantics are now recast as AlwaysInline and
the kw___forceinline token has its language mode set for KEYMS.
This preserves the semantics of the previous implementation but with
less duplication of code.
llvm-svn: 202131
We were previously checking at every destructor declaration, but that was a bit
excessive. Since the deleting destructor is emitted with the vtable, do the
check when the vtable is marked used.
Differential Revision: http://llvm-reviews.chandlerc.com/D2851
llvm-svn: 202046
Most 64-bit targets define int64_t as long int, and AArch64 should
make same definition to follow LP64 model. In GNU tool chain, int64_t
is defined as long int for 64-bit target. So to get consistent with GNU,
it's better Changing int64_t from 'long long int' to 'long int',
otherwise clang will get different name mangling suffix compared with g++.
llvm-svn: 202004
The language forbids defining enums in prototypes, so this check is normally
redundant, but if an enum is defined during template instantiation it should
not be added to the prototype scope.
While at it, clean up the code that deals with tag definitions in prototype
scope and expand the visibility warning to cover the case where an anonymous
enum is defined.
Differential Revision: http://llvm-reviews.chandlerc.com/D2742
llvm-svn: 201927
It was previously thought that Sema::InstantiateClass could not fail
from within this point in instantiate.
However, it can happen if the class is invalid some way (i.e. invalid
base specifier).
This fixes PR18907.
Differential Revision: http://llvm-reviews.chandlerc.com/D2850
llvm-svn: 201913
In particular, if we see an @property within the @interface of a class
conforming to a protocol with this attribute, we treat that as
if the implementation were available, per the rules of default
property synthesis.
llvm-svn: 201911
Because GCC incorrectly defines _mm_prefetch to take anything that casts
to void*, people have started using that behavior. The previous patch
that made _mm_prefetch actually take a const char * broke compatibility
with existing code. This update to the patch leaves the macro that
defines _mm_prefetch with the (void*) cast when _MSC_VER is not defined.
llvm-svn: 201901
We're going to extend DiagnoseUnimplementedProperties shortly to look for more cases
that aren't handled by default property synthesis.
llvm-svn: 201878
This does;
- clang_tablegen() adds each tblgen'd target to global property CLANG_TABLEGEN_TARGETS as list.
- List of targets is added to LLVM_COMMON_DEPENDS.
- all clang libraries and targets depend on generated headers.
You might wonder this would be regression, but in fact, this is little loss.
- Almost all of clang libraries depend on tblgen'd files and clang-tblgen.
- clang-tblgen may cause short stall-out but doesn't cause unconditional rebuild.
- Each library's dependencies to tblgen'd files might vary along headers' structure.
It made hard to track and update *really optimal* dependencies.
Each dependency to intrinsics_gen and ClangSACheckers is left as DEPENDS.
llvm-svn: 201842
This breaks backwards compatibility with existing code. Previously, this
was defined as
#define _mm_prefetch(a, sel) (__builtin_prefetch((void *)(a), 0, (sel)))
Which basically accepts any pointer. Changing this to char* simply
breaks a lot of existing code. I have tried changing char* to
"const void*", which seems to be the right thing as per Intel
specification this should work on basically any pointer. However,
apparently this breaks windows compatibility (because of a conflicting
declaration in windows.h).
So, we probably need to #ifdef this based on whether clang is compiling
for windows. According to Chandler, this might be done by introducing an
additional symbol to a fake type in BuiltinsX86.def and then condition
the type expansion on the platform.
llvm-svn: 201775
This patch adds several built-ins that are required for ms
compatibility. _mm_prefetch must be a built-in because it takes a
compile-time constant argument and our prior approach of using a #define
to the current built-in doesn't work in the presence of re-declaration
of _mm_prefetch. The others can be obtained by including the windows
system headers. If a user includes the windows system headers but not
intrin.h they still need to work and therefore must be built-in because
we don't get a chance to implement them in intrin.h in this case.
llvm-svn: 201734
There are two kinds of automatically generated tests for NEON intrinsics, both
of which can be merged without adversely affecting users.
1. We check that a valid kind of __builtin_neon_XYZ overload is requested (e.g.
we're not asking for a float32x4_t version when it only accepts integers. Since
the __builtin_neon_XYZ intrinsics should only be used in arm_neon.h, relaxing
this test and permitting AArch64 types for AArch32 should not cause a problem.
The extra arm_neon.h definitions should be #ifdefed out anyway.
2. We check that intrinsics which take immediates are actually given
compile-time constants within range. Since all NEON intrinsics should be
backwards compatible, these tests should be identical on AArch64 and AArch32
anyway.
This patch, therefore, merges the separate AArch64 and 32-bit checks.
rdar://problem/16035743
llvm-svn: 201659
DR18 previously forebode typedefs to be used as parameter types if they
were of type 'void'. DR577 allows 'void' to be used as a function
parameter type regardless from where it came.
llvm-svn: 201631
This warning has a whole bunch of known false positives, much of them due
to code that is "sometimes unreachable". This can caused by code that
is conditionally generated by the preprocessor, branches that are defined
in terms of architecture-specific details (e.g., the size of a type), and
so on. While these are all good things to address one by one, the reality
is that this warning has received little love lately. By restricting
its purvue, we can focus on the top issues effecting main files, which
should be smaller, and then gradually widen the scope.
llvm-svn: 201607
The following attributes have been (silently) deprecated, with their replacements listed:
lockable => capability
exclusive_locks_required => requires_capability
shared_locks_required => requires_shared_capability
locks_excluded => requires_capability
There are no functional changes intended.
llvm-svn: 201585
temporary in a decltype expression only applies if that temporary was created
by a function call, not by a function-style cast or other flavour of
expression.
llvm-svn: 201542
and the class name is shadowed by another member. Recovery still needs
to be figured out, which is non-trivial since the parser has already gone
down a much different path than if it had recognized the class template
as type instead of seeing the member that shadowed the class template.
llvm-svn: 201360
These features are new in VS 2013 and are necessary in order to layout
std::ostream correctly. Currently we have an ABI incompatibility when
self-hosting with the 2013 stdlib in our convertible_fwd_ostream wrapper
in gtest.
This change adds another implicit attribute, MSVtorDispAttr, because
implicit attributes are currently the best way to make sure the
information stays on class templates through instantiation.
Reviewers: majnemer
Differential Revision: http://llvm-reviews.chandlerc.com/D2746
llvm-svn: 201274
Previously, range checking on the __builtin_neon_XYZ_v Clang intrinsics didn't
take account of the type actually passed to the call, which meant a request
like "vext_s16(a, b, 7)" was allowed through (TableGen was conservative and
allowed 0-7 for all types). This caused an assert in the backend because the
lane doesn't make sense.
llvm-svn: 201232
These flags control the inheritance model initially used by the
translation unit.
Differential Revision: http://llvm-reviews.chandlerc.com/D2741
llvm-svn: 201175
Thanks to r199467, __attribute__((nonnull)) (without arguments) can apply
directly to parameters, instead of being applied to the whole function.
However, the old form of nonnull (with an argument index) could also apply
to the arguments of function and block pointers, and both of these can be
passed as parameters.
Now, if 'nonnull' with an argument is found on a parameter, /and/ the
parameter is a function or block pointer, it is handled the old way.
PR18795
llvm-svn: 201162
Introduce a notion of a 'current representation method' for
pointers-to-members.
When starting out, this is set to 'best case' (representation method is
chosen by examining the class, selecting the smallest representation
that would work given the class definition or lack thereof).
This pragma allows the translation unit to dictate exactly what
representation to use, similar to how the inheritance model keywords
operate.
N.B. PCH support is forthcoming.
Differential Revision: http://llvm-reviews.chandlerc.com/D2723
llvm-svn: 201105
Rather than simply saying "X is not a class or namespace", clarify what
X is by providing the aka type in the case where X is a type, or
pointing to the named declaration if there's an unambiguous one to refer
to. In the ambiguous case, the ambiguities are already enumerated
(though could be clarified by describing what kind of entities they are)
Included a few FIXMEs in tests where some further improvements could be
made.
llvm-svn: 201038
template parameters, don't look for parameters of outer templates. If a problem
is found in a default template argument, point the diagnostic at the partial
specialization (with a note pointing at the default argument) instead of
pointing it at the default argument and leaving it unclear which partial
specialization os problematic.
llvm-svn: 201031
Summary:
This avoids false positives from -Wmicrosoft when name lookup would
normally succeed in standard C++. This triggered on a common CRTP
pattern in clang, where a derived class would have a private using decl
to pull in members of a dependent base:
class Verifier : InstVisitor<Verifier> {
private:
using InstVisitor<Verifier>::visit;
...
void anything() {
visit(); // warned here
}
};
Real access checks pass here because we're in the context of the
Verifier, but the -Wmicrosoft extension was just looking for the private
access specifier.
Reviewers: rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2679
llvm-svn: 201019
'operator delete' or 'operator delete[]' is an explicit exception
specification. Therefore we should diagnose 'void operator delete(void*)'
instead of 'void operator delete(void*) noexcept'.
This diagnostic remains an ExtWarn, since in practice people don't always
include the exception specification in such a declaration.
llvm-svn: 201002
If we are in the middle of defining the class, don't attempt to
validate previously annotated declarations. We may not have seen base
specifiers or virtual method declarations yet.
llvm-svn: 200959
type-dependent variable, even if the initializer isn't value-dependent. This
happens for ParenListExprs composed of non-value-dependent subexpressions, for
instance.
We should really give ParenListExprs (and InitListExprs) the type of the
initialized entity if they're used to represent a dependent initialization (and
if so, set them to be type-, value- and instantiation-dependent).
llvm-svn: 200954
Properly determine the inheritance model when dealing with nullptr:
- If a nullptr template argument is being checked against
pointer-to-member parameter, nail down an inheritance model.
N.B. We will chose an inheritance model even if we won't ultimately
choose the template to instantiate! Cooky, right?
- Null pointer-to-datamembers have a virtual base table offset of -1,
not zero. Previously, we chose an offset of 0.
llvm-svn: 200920
In the following code:
struct A { static const int sz; };
template<class T> void f() { T arr[A::sz]; }
the array 'arr' is represented as a variable size array in the template.
If 'A::sz' gets value below in the translation unit, the array in
instantiation can turn into constant size array.
This change fixes PR18633.
Differential Revision: http://llvm-reviews.chandlerc.com/D2688
llvm-svn: 200899
using-declaration, and they declare the same function (either because
the using-declaration is in the same namespace as the declaration it
imports, or because they're both extern "C"), they do not conflict.
llvm-svn: 200897
Because in C++, "anonymous" doesn't mean "nameless" for records. In
other words, RecordDecl::isAnonymousStructOrUnion only returns true if
the record lacks a name *and* is not used as the type in an object's
declaration.
llvm-svn: 200868
We accept these with a warning in MS mode, but we would previously mark them
invalid, causing us not to emit code for them.
Differential Revision: http://llvm-reviews.chandlerc.com/D2681
llvm-svn: 200815
When a lax conversion featured a vector and a non-vector, we were
only requiring the non-vector to be a scalar type, but really it
needs to be a real type (i.e. integral or real floating); it is
not reasonable to allow a pointer, member pointer, or complex
type here.
r198474 required lax conversions to match in "data size", i.e.
element size * element count, forbidding matches that happen
only because a vector is rounded up to the nearest power of two
in size. Unfortunately, the erroneous logic was repeated in
several different places; unify them to use the new condition,
so that it triggers for arbitrary conversions and not just
those performed as part of binary operator checking.
rdar://15931426
llvm-svn: 200810
redeclaration, not just when looking them up for a use -- we need the implicit
declaration to appropriately check various properties of them (notably, whether
they're deleted).
llvm-svn: 200729
Aaron Ballman