properly if there is a join point in the control flow graph that involves
a trylock. Also changes the source locations of some warnings to be
more consistent.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159008 91177308-0d34-0410-b5e6-96231b3b80d8
This now correctly covers, I believe, all the pointer types:
* 'any' pointers (both function and data normal pointers and ObjC object pointers)
* member pointers (both function and data)
* block pointers
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158931 91177308-0d34-0410-b5e6-96231b3b80d8
is passed to a variadic function in a position where a format string indicates
that c_str()'s return type is desired, provide a note suggesting that the user
may have intended to call the c_str() member.
Factor the non-POD-vararg checking out of DefaultVariadicArgumentPromotion and
move it to SemaChecking in order to facilitate this. Factor the call checking
out of function call checking and block call checking, and extend it to cover
constructor calls too.
Patch by Sam Panzer!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158887 91177308-0d34-0410-b5e6-96231b3b80d8
It's very easy for anonymous external linkage to propagate in C++ through
return types and parameter types. Likewise, it's possible that a template
containing an inline function is only used with parameters that have internal
linkage. Actually diagnosing where the internal linkage comes from is fairly
difficult (both to locate and then to print nicely). Finally, since we only
have one translation unit available, we can't even prove that any of this
violates the ODR.
This warning needs better-defined behavior in C++ before it can really go in.
Rewording of the C warning (which /is/ specified by C99) coming shortly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158836 91177308-0d34-0410-b5e6-96231b3b80d8
because it expects a reference and receives a non-l-value.
For example, given:
int foo(int &);
template<int x> void b() { foo(x); }
clang will now print "expects an l-value for 1st argument" instead of
"no known conversion from 'int' to 'int &' for 1st argument". The change
in wording (and associated code to detect the case) was prompted by
comment #5 in PR3104, and should be the last bit of work needed for the
bug.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158691 91177308-0d34-0410-b5e6-96231b3b80d8
Per post-commit review, it's not appropriate to use ExtWarn in C++, because
we can't prove that the inline function will actually be defined in more than
one place (and thus we can't prove that this violates the ODR).
This removes the warning entirely from uses in the main source file in C++.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158689 91177308-0d34-0410-b5e6-96231b3b80d8
This includes treating anonymous namespaces like internal linkage, and allowing
const variables to be used even if internal. The whole thing's been broken out
into a separate function to avoid nested ifs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158683 91177308-0d34-0410-b5e6-96231b3b80d8
Now, as long as the 'Namespaces' variable is correct inside Attr.td, the
generated code will correctly admit a C++11 attribute only when it has the
appropriate namespace(s).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158661 91177308-0d34-0410-b5e6-96231b3b80d8
are otherwise too short to try to correct.
The TODOs added to two of the tests are for existing deficiencies in the
typo correction code that could be exposed by using longer identifiers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158109 91177308-0d34-0410-b5e6-96231b3b80d8
temporary or an array subobject of a class temporary, and the resulting value
is used to initialize a pointer which outlives the temporary. Such a pointer
is always left dangling after the initialization completes and the array's
lifetime ends.
In order to detect this situation, this change also adds an
LValueClassification of LV_ArrayTemporary for temporaries of array type which
aren't subobjects of class temporaries. These occur in C++11 T{...} and GNU C++
(T){...} expressions, when T is an array type. Previously we treated the former
as a generic prvalue and the latter as a class temporary.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@157955 91177308-0d34-0410-b5e6-96231b3b80d8
involving 'restrict', place restrict on the pointer type rather than
on the pointee type. Also make sure that we gather restrict from the
pointer type. Fixes PR12854 and the major part of PR11093.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@157910 91177308-0d34-0410-b5e6-96231b3b80d8
but different nested name specifiers to quietly clobber each other so
only one remains if they do not refer to the same NamedDecl. Fixes
PR12951.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@157823 91177308-0d34-0410-b5e6-96231b3b80d8
This is a large class of false positives where anonymous enums are used to
declare constants (see Clang's Diagnostics.h for example). A small number of
true positives could probably be found in this bucket by still warning if the
anonymous enum is used in a declarator (enum { ... } x;) but so far we don't
believe this to be a source of significant benefit so I haven't bothered to
preserve those cases.
General offline review/acknowledgment by rtrieu.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@157713 91177308-0d34-0410-b5e6-96231b3b80d8
same value and were initialized with literals. Clang will warn on code like
this:
enum A {
FIRST = 1,
SECOND = 1
};
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@157666 91177308-0d34-0410-b5e6-96231b3b80d8
The DenseMap reallocates after 64 insertions so this only happened in
large test cases under very specific circumstances.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@157549 91177308-0d34-0410-b5e6-96231b3b80d8
volatile reference to a temporary is not viable. My interpretation is that
DR1152 was a bugfix, not a rule change for C++11, so this is not conditional on
the language mode. This matches g++'s behavior.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@157370 91177308-0d34-0410-b5e6-96231b3b80d8
Disambiguate past such a potential problem, and use the absence of 'typename'
to break ties in favor of a parenthesized thingy being an initializer, if
nothing else in the declaration disambiguates it as declaring a function.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156963 91177308-0d34-0410-b5e6-96231b3b80d8
This improves the conversion diagnostics (by correctly pointing to the loop
construct for conversions that may've been caused by the contextual conversion
to bool caused by a condition expression) and also causes the NULL conversion
warnings to be correctly suppressed when crossing a macro boundary in such a
context. (previously, since the conversion context location was incorrect, the
suppression could not be performed)
Reported by Nico Weber as feedback to r156826.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156901 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes the included test case & was reported by Nico Weber.
It's a little bit nasty using the difference in the conversion context, but
seems to me like a not unreasonable solution. I did have to fix up the
conversion context for conditional operators (it seems correct to me to include
the context for which we're actually doing the comparison - across all the
nested conditionals, rather than the innermost conditional which might not
actually have the problematic implicit conversion at all) and template default
arguments (this is a bit of a hack, since we don't have the source location of
the '=' anymore, so I just used the start of the parameter - open to
suggestions there)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156861 91177308-0d34-0410-b5e6-96231b3b80d8
and the thing we have has a scope specifier, and we're in a context that doesn't
allow declaring a qualified name, then the error is a malformed type, not a
missing type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156856 91177308-0d34-0410-b5e6-96231b3b80d8
Moves the bool bail-out down a little in SemaChecking - so now
-Wnull-conversion and -Wliteral-conversion can fire when the target type is
bool.
Also improve the wording/details in the -Wliteral-conversion warning to match
the -Wconstant-conversion.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156826 91177308-0d34-0410-b5e6-96231b3b80d8