llvm-svn: 88732

llvm-svn: 87087

Allow Preprocessor to take ownership of the HeaderSearch object. I think it should probably always own the header search object, but I'm not sure...

llvm-svn: 86882

a little fuzzy, but conceptually it's just uniquing the identifier.

Chris, please review. I debated splitting into const/non-const versions where
the const one propogated constness to the resulting IdentifierInfo*.

llvm-svn: 86106

llvm-svn: 86105

llvm-svn: 86076

llvm-svn: 84436

only supporting a single stat cache. The immediate benefit of this
change is that we can now generate a PCH/AST file when including
another PCH file; in the future, the chain of stat caches will likely
be useful with multiple levels of PCH files.

llvm-svn: 84263

  -code-completion-at=filename:line:column

which performs code completion at the specified location by truncating
the file at that position and enabling code completion. This approach
makes it possible to run multiple tests from a single test file, and
gives a more natural command-line interface.

llvm-svn: 82571

essence, code completion is triggered by a magic "code completion"
token produced by the lexer [*], which the parser recognizes at
certain points in the grammar. The parser then calls into the Action
object with the appropriate CodeCompletionXXX action.

Sema implements the CodeCompletionXXX callbacks by performing minimal
translation, then forwarding them to a CodeCompletionConsumer
subclass, which uses the results of semantic analysis to provide
code-completion results. At present, only a single, "printing" code
completion consumer is available, for regression testing and
debugging. However, the design is meant to permit other
code-completion consumers.

This initial commit contains two code-completion actions: one for
member access, e.g., "x." or "p->", and one for
nested-name-specifiers, e.g., "std::". More code-completion actions
will follow, along with improved gathering of code-completion results
for the various contexts.

[*] In the current -code-completion-dump testing/debugging mode, the
file is truncated at the completion point and EOF is translated into
"code completion".

llvm-svn: 82166

llvm-svn: 81346

llvm-svn: 79854

declaration in the AST. 

The new ASTContext::getCommentForDecl function searches for a comment
that is attached to the given declaration, and returns that comment, 
which may be composed of several comment blocks.

Comments are always available in an AST. However, to avoid harming
performance, we don't actually parse the comments. Rather, we keep the
source ranges of all of the comments within a large, sorted vector,
then lazily extract comments via a binary search in that vector only
when needed (which never occurs in a "normal" compile).

Comments are written to a precompiled header/AST file as a blob of
source ranges. That blob is only lazily loaded when one requests a
comment for a declaration (this never occurs in a "normal" compile). 

The indexer testbed now supports comment extraction. When the
-point-at location points to a declaration with a Doxygen-style
comment, the indexer testbed prints the associated comment
block(s). See test/Index/comments.c for an example.

Some notes:
  - We don't actually attempt to parse the comment blocks themselves,
  beyond identifying them as Doxygen comment blocks to associate them
  with a declaration.
  - We won't find comment blocks that aren't adjacent to the
  declaration, because we start our search based on the location of
  the declaration.
  - We don't go through the necessary hops to find, for example,
  whether some redeclaration of a declaration has comments when our
  current declaration does not. Similarly, we don't attempt to
  associate a \param Foo marker in a function body comment with the
  parameter named Foo (although that is certainly possible).
  - Verification of my "no performance impact" claims is still "to be
  done".

llvm-svn: 74704

registered when PCH wasn't being used.  We should always install (in BuiltinInfo)
information about target-specific builtins, but we shouldn't register any builtin
identifier infos.  This fixes the build of apps that use PCH and target specific
builtins together.

llvm-svn: 73492

llvm-svn: 70283

the first real character of a token.  For example, advancing
to byte 3 of foo\
bar

should stop at the b, not the \.

llvm-svn: 69484

llvm-svn: 69479

This allows it to accurately measure tokens, so that we get:

t.cpp:8:13: error: unknown type name 'X'
static foo::X  P;
       ~~~~~^

instead of the woefully inferior:

t.cpp:8:13: error: unknown type name 'X'
static foo::X  P;
       ~~~~ ^

Most of this is just plumbing to push the reference around.

llvm-svn: 69099

llvm-svn: 68933

buffer generated for the current translation unit. If they are
different, complain and then ignore the PCH file. This effectively
checks for all compilation options that somehow would affect
preprocessor state (-D, -U, -include, the dreaded -imacros, etc.).

When we do accept the PCH file, throw away the contents of the
predefines buffer rather than parsing them, since all of the results
of that parsing are already stored in the PCH file. This eliminates
the ugliness with the redefinition of __builtin_va_list, among other
things.

llvm-svn: 68838

PCH.  This works now, except for limitations not being able to do things
with identifiers.  The basic example in the testcase works though.

llvm-svn: 68832

into clang-cc.cpp.  This makes it so clang-cc constructs the *entire* predefines 
buffer, not just half of it.  A bonus of this is that we get to kill a copy
of DefineBuiltinMacro.

llvm-svn: 68830

improvement, source locations read from the PCH file will properly
resolve to the source files that were used to build the PCH file
itself.

Once we have the preprocessor state stored in the PCH file, source
locations that refer to macro instantiations that occur in the PCH
file should have the appropriate instantiation information.

llvm-svn: 68758

 - Add -static-define option driver can use when __STATIC__ should be
   defined (instead of __DYNAMIC__).

 - Don't set __OPTIMIZE_SIZE__ on Os, __OPTIMIZE_SIZE__ is tied to Oz.

 - Set __NO_INLINE__ following GCC 4.2.

 - Set __GNU_GNU_INLINE__ or __GNU_STDC_INLINE__ following GCC 4.2.

 - Set __EXCEPTIONS for Objective-C NonFragile ABI.

 - Set __STRICT_ANSI__ for standard conforming modes.

 - I added a clang style test case in utils for this, but its not
   particularly portable and I don't think it belongs in the test
   suite.

llvm-svn: 68621

 - Add -pic-level clang-cc option to specify the value for the define,
   updated driver to pass this.

 - Added __pic__

 - Added OBJC_ZEROCOST_EXCEPTIONS define while I was here (to match gcc).

llvm-svn: 68584

and are even set in C mode.  As such, move them to Targets.cpp.

__OBJC_GC__ is also darwin specific, but seems reasonable to always
define it when in objc-gc mode.

This fixes rdar://6761450

llvm-svn: 68494

llvm-svn: 68450

llvm-svn: 67802

- Temporarily undef'ed __OBJC2__ in nonfragile objc abi mode
  as it was forcing ivar synthesis in a certain project which clang
  does not yet support.

llvm-svn: 67766

change the __VERSION__ string to be more sensible.  It would be useful to include the clang version # too.

llvm-svn: 67619

Add a #include directive around the command line buffer so that
diagnostics generated from -include directives get diagnostics
like:

In file included from <built-in>:98:
In file included from <command line>:3:
./t.h:2:1: warning: type specifier missing, defaults to 'int'
b;
^

llvm-svn: 67396

can have language-specific defines.

llvm-svn: 67375

llvm-svn: 67032

llvm-svn: 66955

llvm-svn: 66474

llvm-svn: 66344

llvm-svn: 65884

llvm-svn: 65641

to being allocated from the same bumpptr that the MacroInfo objects 
themselves are.

This speeds up -Eonly cocoa.h pth by ~4%, fsyntax-only is barely measurable.

llvm-svn: 65195

llvm-svn: 65187