name of the tracked function.

llvm-svn: 70381

llvm-svn: 70380

llvm-svn: 70373

1. In a struct field redefinition, don't mark the struct erroneous.  The
   field is erroneous, but the struct is otherwise well formed.
2. Don't emit diagnostics about functions that are known to be broken already.

Either fix is sufficient to silence the second diagnostic in the example,
but the combination is better :)

llvm-svn: 70371

llvm-svn: 70369

This enables one specific class of non-literal format warnings.

llvm-svn: 70368

llvm-svn: 70367

llvm-svn: 70361

llvm-svn: 70358

llvm-svn: 70353

on ObjCMessageExpr. This will enable us to use it elsewhere. This should not
change any functionality.

llvm-svn: 70352

llvm-svn: 70339

lines that clang extracts from the source code so that machine parsing can
easily ignore them.

llvm-svn: 70337

to add 'CFMakeCollectable' semantics to a method.

llvm-svn: 70336

compilation if the user requested a PCH file but no such PCH file
exists.

llvm-svn: 70332

llvm-svn: 70330

and apparently not part of -Wall

llvm-svn: 70329

now gotten back about 180k of the 500k we lost.

llvm-svn: 70326

which eliminates the storage for IdentifierInfo in the "uninteresting
identifier" cases. Sadly, this only brought back 7k of the 500k we
lost :(

llvm-svn: 70325

llvm-svn: 70322

line when using a PCH that were not provided when building the PCH
file. If those names were used as identifiers somewhere in the PCH
file, reject the PCH file.

llvm-svn: 70321

for identifiers to separate "interesting" from "uninteresting"
identifiers. However, to cope with compiler invocations where the
predefines buffers mismatch, we need to be able to search the complete
identifier table. Cocoa.h.pch is now about 500k larger that it used to
be :(

llvm-svn: 70320

regardless of extension.
 - Otherwise we can't expect that just plugging in -ccc-pch-is-pch
   will work.

llvm-svn: 70318

llvm-svn: 70317

PCH file and the predefines buffer used when including the PCH
file. We (explicitly) detect conflicting macro definitions (rejecting
the PCH file) and about missing macro definitions (they'll be
automatically pulled from the PCH file anyway).

We're missing some checking to make sure that new macro definitions
won't have any impact on the PCH file itself (e.g., #define'ing an
identifier that the PCH file used).

llvm-svn: 70316

llvm-svn: 70315

llvm-svn: 70313

"function designator".

(This causes a minor glitch in the 
diagnostics for C++ member pointers, but we weren't printing the 
right diagnostic there anyway.)

llvm-svn: 70307

llvm-svn: 70293

mode and in the presence of __gnu_inline__ attributes. This should fix
both PR3989 and PR4069.

As part of this, we now keep track of all of the attributes attached
to each declaration even after we've performed declaration
merging. This fixes PR3264.

llvm-svn: 70292

llvm-svn: 70286

add "Looping back to the head of the loop" diagnostic for loops.

llvm-svn: 70285

llvm-svn: 70284

llvm-svn: 70283

llvm-svn: 70282

scheme to be more useful.

The new scheme introduces a set of categories that should be more 
readable, and also reflects what we want to consider as an extension 
more accurately.  Specifically, it makes the "what is a keyword" 
determination accurately reflect whether the keyword is a GNU or 
Microsoft extension.

I also introduced separate flags for keyword aliases; this is useful 
because the classification of the aliases is mostly unrelated to the 
classification of the original keyword.

This patch treats anything that's in the implementation 
namespace (prefixed with "__", or "_X" where "X" is any upper-case 
letter) as a keyword without marking it as an extension.  This is 
consistent with the standards in that an implementation is allowed to define 
arbitrary extensions in the implementation namespace without violating 
the standard. This gets rid of all the nasty "extension used" warnings 
for stuff like __attribute__ in -pedantic mode.  We still warn for 
extensions outside of the the implementation namespace, like typeof.
If someone wants to implement -Wextensions or something like that, we 
could add additional information to the keyword table.

This also removes processing for the unused "Boolean" language option; 
such an extension isn't supported on any other C implementation, so I 
don't see any point to adding it.

The changes to test/CodeGen/inline.c are required because previously, we 
weren't actually disabling the "inline" keyword in -std=c89 mode.

I'll remove Boolean and NoExtensions from LangOptions in a follow-up 
commit.

llvm-svn: 70281

llvm-svn: 70280

llvm-svn: 70277

- Add 'LoopTarget' pointer field to CFGBlock. This records if the block is used
  as the 'loop back' path back to the head of a loop.
- For ForStmt, encode the loop back target as the increment code.

llvm-svn: 70274

that if we're going to print an extension warning anyway, 
there's no point to changing behavior based on NoExtensions: it will 
only make error recovery worse.

Note that this doesn't cause any behavior change because NoExtensions 
isn't used by the current front-end.  I'm still considering what to do about
the remaining use of NoExtensions in IdentifierTable.cpp.

llvm-svn: 70273