| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
No functional change, this code was just superfluous.
llvm-svn: 201099
|
| |
|
|
|
|
|
| |
nested-name-specifiers for typos unless the typo already has
a nested-name-specifier that is a template specialization.
llvm-svn: 201056
|
| |
|
|
| |
llvm-svn: 201040
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
name specifier.
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
|
| |
|
|
|
|
| |
whether it's POD.
llvm-svn: 201018
|
| |
|
|
| |
llvm-svn: 201012
|
| |
|
|
|
|
|
|
|
|
|
| |
'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
|
| |
|
|
| |
llvm-svn: 201000
|
| |
|
|
|
|
| |
internal discussions. // rdar://16006401
llvm-svn: 200986
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
expression.
llvm-svn: 200948
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 200723
|
| |
|
|
|
|
| |
In MSVC, enums are always signed unless you explicitly specify the type.
llvm-svn: 200719
|
| |
|
|
|
|
| |
variable template until we know what the template arguments actually are.
llvm-svn: 200714
|
| |
|
|
| |
llvm-svn: 200681
|
| |
|
|
|
|
| |
(which implemented the DR) was disabled in C++11.
llvm-svn: 200673
|
| |
|
|
|
|
|
| |
Otherwise we'd accept them if the LinkageDecl was not the direct
parent DeclContext. PR17968.
llvm-svn: 200641
|
| |
|
|
|
|
| |
and revert its behavior for C++.
llvm-svn: 200622
|
| |
|
|
|
|
|
|
|
|
| |
casts, which are used
by some projects in their null macro.
rdar://15925483
llvm-svn: 200521
|
| |
|
|
|
|
| |
processing. (http://llvm-reviews.chandlerc.com/D2451)
llvm-svn: 200513
|
| |
|
|
|
|
|
| |
operator--, since it might instantiate as 'int' (or, if it's a pack, it
might instantiate as an empty pack).
llvm-svn: 200496
|
| |
|
|
|
|
|
| |
reference (or pointer) to a variable from the closure object or from the
surrounding function scope.
llvm-svn: 200494
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
a previously-computed linkage as an unsupportable error condition.
Per discussion on cfe-commits, this appears to be a
difficult-to-resolve flaw in our implementation approach;
we may pursue this as a language defect, but for now it's
better to diagnose it as unsupported than to produce
inconsistent results (or assertions). Anything that we can
do to limit how often this diagnostic fires, such as the
changes in r200380, is probably for the best, though.
llvm-svn: 200438
|
| |
|
|
|
|
|
|
|
|
|
| |
We would previously allow inappropriate inheritance keywords to appear
on class declarations. We would also allow inheritance keywords on
templates which were not fully specialized; this was divergent from
MSVC.
Differential Revision: http://llvm-reviews.chandlerc.com/D2585
llvm-svn: 200423
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
the linkage cache) when type-checking static local
variables.
There's a very deep problem here where the linkage of
a declaration can suddenly massively change as soon as
it's given a typedef name; these fixes, while optimizations
in their own right, are really just targeted workarounds.
rdar://15928125
llvm-svn: 200380
|
| |
|
|
|
|
|
|
|
| |
cast into a boolean true value. This warning will catch code like:
if (@0) {}
if (@"foo") {}
llvm-svn: 200356
|
| |
|
|
|
|
|
| |
was not being overridden in the category method implementation
resulting in bogus warning. // rdar://15919775
llvm-svn: 200342
|
| |
|
|
|
|
|
|
| |
the diagnostic only when subsequent alignments are more strict than the alignment required by the first field.
Fixes PR15134
llvm-svn: 200277
|
| |
|
|
|
|
|
|
| |
case when correcting for too many arguments (r191450 had only fixed the
problem for when there were too few arguments). Also fix the underlining
for both cases.
llvm-svn: 200268
|
| |
|
|
|
|
|
| |
backing a property resulting in bogus warning.
// rdar://15890251
llvm-svn: 200254
|
| |
|
|
|
|
|
|
| |
spelling, and a CXX11 spelling with the namespace "gnu". It also sets a bit on the spelling certifying that it is known to GCC. From this, we can warn about the extension appropriately. As a consequence, the FunctionDefinition functionality is completely removed.
Replacing the functionality from r199676, which didn't solve the problem as elegantly.
llvm-svn: 200252
|
| |
|
|
|
|
|
|
| |
parimary class and in mrr mode, assume property's default
memory attribute (assign) and to prevent a bogus warning.
// rdar://15859862
llvm-svn: 200238
|
| |
|
|
|
|
|
| |
throw-expression, the result is also a glvalue and isn't unnecessarily coerced
to a prvalue.
llvm-svn: 200189
|
| |
|
|
|
|
|
|
| |
Follow up to r200082.
Spotted by Dmitri
llvm-svn: 200105
|
| |
|
|
|
|
| |
'template<>' on a variable template explicit specialization.
llvm-svn: 200099
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A return type is the declared or deduced part of the function type specified in
the declaration.
A result type is the (potentially adjusted) type of the value of an expression
that calls the function.
Rule of thumb:
* Declarations have return types and parameters.
* Expressions have result types and arguments.
llvm-svn: 200082
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously, string literals were ignored in all logical expressions. This
reduces it to only ignore in logical and expressions.
assert(0 && "error"); // No warning
assert(0 || "error"); // Warn
Fixes PR17565
llvm-svn: 200056
|
| |
|
|
|
|
| |
have a meaningful semantic spelling. Adds a sibling function to parsed attribtues (via AttributeList) for getting the semantic spelling, if one were to exist. This can be used for cleaner code that deals directly with the semantic spellings (such as the MSInheritance attribute).
llvm-svn: 200041
|
| |
|
|
|
|
|
| |
This is the second msan failure where UserDefinedConversion does not initialize
its `Before` member as identity conversion.
llvm-svn: 199997
|