| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
destination type for initialization, assignment, parameter-passing,
etc. The main issue fixed here is that we used rather confusing
wording for diagnostics such as
t.c:2:9: warning: initializing 'char const [2]' discards qualifiers,
expected 'char *' [-pedantic]
char *name = __func__;
^ ~~~~~~~~
We're not initializing a 'char const [2]', we're initializing a 'char
*' with an expression of type 'char const [2]'. Similar problems
existed for other diagnostics in this area, so I've normalized them all
with more precise descriptive text to say what we're
initializing/converting/assigning/etc. from and to. The warning for
the code above is now:
t.c:2:9: warning: initializing 'char *' from an expression of type
'char const [2]' discards qualifiers [-pedantic]
char *name = __func__;
^ ~~~~~~~~
Fixes <rdar://problem/7447179>.
llvm-svn: 100832
|
| |
|
|
|
|
|
| |
warning. It's not harmful to have such pointless declarations, and GCC
does not diagnose this issue consistently.
llvm-svn: 100814
|
| |
|
|
|
|
| |
of c-style arguments. Completes radar 7445205.
llvm-svn: 100813
|
| |
|
|
|
|
| |
variable declarations.
llvm-svn: 100809
|
| |
|
|
|
|
| |
Fixes PR6752.
llvm-svn: 100806
|
| |
|
|
|
|
|
|
|
|
| |
inline' functions
unless they are used. I discussed this with Daniel Dunbar, and we agreed that this
provides an inconsistent warnings experience for the user and that there were
genuine cases where we wouldn't want to do this optimization.
llvm-svn: 100800
|
| |
|
|
|
|
|
|
|
| |
<tr1/hashtable> header, where a friend class template
std::tr1::__detail::_Map_base is declared with the wrong template
parameters. GCC doesn't catch the problem, so Clang does a little
back-flip to avoid diagnosing just this one instance of the problem.
llvm-svn: 100790
|
| |
|
|
|
|
|
| |
Declarator that depends on it. This fixes several redundant errors and bad
recoveries.
llvm-svn: 100779
|
| |
|
|
| |
llvm-svn: 100753
|
| |
|
|
| |
llvm-svn: 100750
|
| |
|
|
|
|
| |
-dump-record-layouts a bit that Sema honors.
llvm-svn: 100747
|
| |
|
|
|
|
| |
methods. wip.
llvm-svn: 100734
|
| |
|
|
| |
llvm-svn: 100732
|
| |
|
|
| |
llvm-svn: 100730
|
| |
|
|
|
|
|
| |
parameter, explicitly ask the user to give it arguments. We used to
complain that it wasn't a type and expect the user to figure it out.
llvm-svn: 100729
|
| |
|
|
|
|
| |
isNotEmpty calls.
llvm-svn: 100722
|
| |
|
|
|
|
|
| |
code won't actually get used yet because we don't handle non-type
parameter packs, but when we do, this code should jump in and work.
llvm-svn: 100716
|
| |
|
|
| |
llvm-svn: 100707
|
| |
|
|
| |
llvm-svn: 100704
|
| |
|
|
|
|
|
|
|
| |
isn't any extra work to perform. Also, don't check for unused
parameters when the warnings will be suppressed anyway. Improves
performance of -fsyntax-only on 403.gcc's combine.c by ~2.5%.
<rdar://problem/7836787>
llvm-svn: 100686
|
| |
|
|
|
|
|
|
|
|
|
| |
- When instantiating a friend type template, perform semantic
analysis on the resulting type.
- Downgrade the errors concerning friend type declarations that do
not refer to classes to ExtWarns in C++98/03. C++0x allows
practically any type to be befriended, and ignores the friend
declaration if the type is not a class.
llvm-svn: 100635
|
| |
|
|
|
|
|
|
| |
semantic analysis) and Sema::ActOnFriendTypeDecl (the action
callback). This is a prerequisite for improving template instantiation
of friend type declarations.
llvm-svn: 100633
|
| |
|
|
|
|
| |
Fixes a spurious warning in LLVM.
llvm-svn: 100595
|
| |
|
|
|
|
|
|
| |
have a temporary object in C++.
Also fix a tag mismatch that Doug noticed.
llvm-svn: 100593
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
definitions, e.g., after
-
or
- (id)
we'll find all of the "likely" instance methods that one would want to
declare or define at this point. In the latter case, we only produce
results whose return types match "id".
llvm-svn: 100587
|
| |
|
|
| |
llvm-svn: 100583
|
| |
|
|
|
|
| |
Fixes radar 7823675.
llvm-svn: 100582
|
| |
|
|
|
|
| |
declared in categories.
llvm-svn: 100577
|
| |
|
|
|
|
|
| |
(void*) someFunction(5, 10, 15, 20);
where the cast is presumably meant to be to 'void'.
llvm-svn: 100574
|
| |
|
|
|
|
|
|
| |
that protected members be used on objects of types which derive from the
naming class of the lookup. My first N attempts at this were poorly-founded,
largely because the standard is very badly worded here.
llvm-svn: 100562
|
| |
|
|
|
|
|
| |
while we're completing in the middle of a function call), also produce
"ordinary" name results that show what can be typed at that point.
llvm-svn: 100558
|
| |
|
|
| |
llvm-svn: 100557
|
| |
|
|
|
|
|
| |
statement or for ordinary names. This means that we won't show macros
when completing, e.g., member expressions such as "p->".
llvm-svn: 100555
|
| |
|
|
|
|
|
| |
down the set of code-completion results based on Objective-C
conventions.
llvm-svn: 100548
|
| |
|
|
|
|
|
|
| |
presence of precompiled headers by forcibly loading all of the
methods we know about from the PCH file before constructing our
code-completion list.
llvm-svn: 100535
|
| |
|
|
|
|
|
|
|
|
| |
"id" or an expression of type "id". In these cases, we produce a list
of all of the (class or instance) methods, respectively, that we know about.
Note that this implementation does not yet work well with precompiled
headers; that's coming soon.
llvm-svn: 100528
|
| |
|
|
| |
llvm-svn: 100496
|
| |
|
|
|
|
| |
CheckObjCPropertyAttributes() early if the Decl* is null.
llvm-svn: 100483
|
| |
|
|
|
|
|
| |
of file locations for anonymous tag types (e.g., "enum <anonymous at
t.h:15:6>"), which can get rather long.
llvm-svn: 100470
|
| |
|
|
|
|
|
| |
of macro definitions when passed to CIndex. Add test for code
completion of macros via CIndex.
llvm-svn: 100431
|
| |
|
|
|
|
| |
(radar 7822210).
llvm-svn: 100226
|
| |
|
|
|
|
|
| |
property is being accessed without the dot-syntax notation.
(radar 7822344).
llvm-svn: 100212
|
| |
|
|
| |
llvm-svn: 100210
|
| |
|
|
|
|
| |
type.
llvm-svn: 100197
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
poor (and wrong) approximation of the actual rules governing when to
build a copy and when it can be elided.
The correct implementation is actually simpler than the
approximation. When we only enumerate constructors as part of
initialization (e.g., for direct initialization or when we're copying
from a class type or one of its derived classes), we don't create a
copy. When we enumerate all conversion functions, we do create a
copy. Before, we created some extra copies and missed some
others. The new test copy-initialization.cpp shows a case where we
missed creating a (required, non-elidable) copy as part of a
user-defined conversion, which resulted in a miscompile. This commit
also fixes PR6757, where the missing copy made us reject well-formed
code in the ternary operator.
This commit also cleans up our handling of copy elision in the case
where we create an extra copy of a temporary object, which became
necessary now that we produce the right copies. The code that seeks to
find the temporary object being copied has moved into
Expr::getTemporaryObject(); it used to have two different
not-quite-the-same implementations, one in Sema and one in CodeGen.
Note that we still do not attempt to perform the named return value
optimization, so we miss copy elisions for return values and throw
expressions.
llvm-svn: 100196
|
| |
|
|
|
|
| |
initializers as they are written. Fixes a bug where we wouldn't show initialization order warnings when instantiating.
llvm-svn: 100180
|
| |
|
|
| |
llvm-svn: 100179
|
| |
|
|
| |
llvm-svn: 100175
|
| |
|
|
| |
llvm-svn: 100174
|
| |
|
|
| |
llvm-svn: 100173
|