suggestions follow recovery. Additionally, add a note to these
diagnostics which suggests a fix-it for changing the behavior to what
the user probably meant. Examples:
t.cpp:2:9: warning: & has lower precedence than ==; == will be evaluated first
[-Wparentheses]
if (i & j == k) {
^~~~~~~~
( )
t.cpp:2:9: note: place parentheses around the & expression to evaluate it first
if (i & j == k) {
^
( )
t.cpp:14:9: warning: using the result of an assignment as a condition
without
parentheses [-Wparentheses]
if (i = f()) {
~~^~~~~
( )
t.cpp:14:9: note: use '==' to turn this assignment into an equality
comparison
if (i = f()) {
^
==
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@92975 91177308-0d34-0410-b5e6-96231b3b80d8
implicitness without losing track of the (logical or actual) location
where "this" would occur in the source.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@92958 91177308-0d34-0410-b5e6-96231b3b80d8
as a type or scope token if the next token requires it.
This eliminates a lot of redundant lookups in C++, but there's room for
improvement; a better solution would do a single lookup whose kind and
results would be passed through the parser.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@92930 91177308-0d34-0410-b5e6-96231b3b80d8
no viable overloads. Use a different message when the class provides
no operator[] overloads at all; use it for operator(), too.
Partially addresses PR 5900.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@92894 91177308-0d34-0410-b5e6-96231b3b80d8
piece of the declaration. The '@' and the 'end' are separate tokens,
and require two SourceLocations to accurately track.
This change was motivated because ObjCContainerDecl::getSourceRange()
would previously not return the entire range of the declaration (the
'end' would be left off).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@92891 91177308-0d34-0410-b5e6-96231b3b80d8
we look into a Scope that corresponds to a compound statement whose
scope was combined with the scope of the function that owns it. This
improves typo correction in many common cases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@92879 91177308-0d34-0410-b5e6-96231b3b80d8
corresponding @interface, provide a note showing which interface we're
referring to. This note has the fix-it hint on it.
Also, don't automatically apply fix-it hints for notes. They're meant
to express fix-its that would change semantics.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@92870 91177308-0d34-0410-b5e6-96231b3b80d8
linkage of vtables. Before this, we were emitting RTTI names for
template instantiations with strong external linkage rather than with
weak ODR linkage.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@92857 91177308-0d34-0410-b5e6-96231b3b80d8
continuation classes and its original declaration
is imported from a protocol. This fixes radar 7509234.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@92856 91177308-0d34-0410-b5e6-96231b3b80d8
result for a nested class whose first non-pure virtual member function
has an inline body. Previously, we were checking for the key function
before we had seen the (delayed) inline body.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@92839 91177308-0d34-0410-b5e6-96231b3b80d8
as parts of overload sets. Also, refer to constructors as 'constructors'
rather than functions.
Adjust a lot of tests.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@92832 91177308-0d34-0410-b5e6-96231b3b80d8
for -Wsign-compare and -Wconversion, and use that coordinated logic to drive
both diagnostics. The new logic works more transparently with implicit
conversions, conditional operators, etc., as well as bringing -Wconversion's
ability to deal with pseudo-closed operations (e.g. arithmetic on shorts) to
-Wsign-compare.
Fixes PRs 5887, 5937, 5938, and 5939.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@92823 91177308-0d34-0410-b5e6-96231b3b80d8
deterministic and work properly with templates. Once a class that
needs a vtable has been defined, we now do one if two things:
- If the class has no key function, we place the class on a list of
classes whose virtual functions will need to be "marked" at the
end of the translation unit. The delay until the end of the
translation unit is needed because we might see template
specializations of these virtual functions.
- If the class has a key function, we do nothing; when the key
function is defined, the class will be placed on the
aforementioned list.
At the end of the translation unit, we "mark" all of the virtual
functions of the classes on the list as used, possibly causing
template instantiation and other classes to be added to the
list. This gets LLVM's lib/Support/CommandLine.cpp compiling again.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@92821 91177308-0d34-0410-b5e6-96231b3b80d8
try to evaluate an expression as a constant boolean condition. This has
the same intended semantics as used in folding conditional operators.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@92805 91177308-0d34-0410-b5e6-96231b3b80d8
non-inline key function of a class template instantiation, when no key
function is present, the class template instantiation itself was
instantiated with an explicit instantiation declaration (aka extern
template). I'm fairly certain that the C++0x specification gives us
this lattitude, although GCC doesn't take advantage of it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@92779 91177308-0d34-0410-b5e6-96231b3b80d8
- All classes can have a key function; templates don't change that.
non-template classes when computing the key function.
- We always mark all of the virtual member functions of class
template instantiations.
- The vtable for an instantiation of a class template has weak
linkage.
We could probably use available_externally linkage for vtables of
classes instantiated by explicit instantiation declarations (extern
templates), but GCC doesn't do this and I'm not 100% that the ABI
permits it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@92753 91177308-0d34-0410-b5e6-96231b3b80d8
related to <rdar://problem/6596843> clang ObjC rewriter: Line endings still mixed in rewrite output
This fix was dropped when I integrated the 'objective-rewrite' branch.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@92737 91177308-0d34-0410-b5e6-96231b3b80d8
Fariborz Jahanian
John McCall
Eli Friedman
Douglas Gregor
David Chisnall
Kovarththanan Rajaratnam
Ted Kremenek
Nuno Lopes
Chris Lattner
Daniel Dunbar
Mike Stump
Steve Naroff