That commit added a new library just to hold the RawCommentList. I've
started a discussion on the commit thread about whether that is really
meritted -- it certainly doesn't seem necessary at this stage.

However, the immediate problem is that the AST library has a hard
dependency on the Comment library, but the dependencies were set up
completely backward. In addition to the layering violation, this had an
unfortunate effect if scattering the Comments library dependency
throughout the build system, but inconsistently so -- several parts of
the CMake dependencies were missing and only showed up due to transitive
deps or the fact that the target wasn't being built by tho bots.

It turns out that the Comments library can't (currently) be a well
formed layer *below* the AST library either, as it has an API that
accepts an ASTContext. That parameter is currently unused, so maybe that
was a mistake?

Anyways, it really seems like this is logically part of the AST --
that's the whole point of the ASTContext providing access to it as far
as I can tell -- so I've merged it into the AST library to solve the
immediate layering violation problems and remove some of the churn from
our library dependencies.

llvm-svn: 158807

* Retain comments in the AST
* Serialize/deserialize comments
* Find comments attached to a certain Decl
* Expose raw comment text and SourceRange via libclang

llvm-svn: 158771

llvm-svn: 154672

Provides an API to run clang tools (FrontendActions) as standalone tools,
or repeatedly in-memory in a process. This is useful for unit-testing,
map-reduce style applications, source transformation daemons or command line
tools.

The ability to run over multiple translation units with different command
line arguments enables building up refactoring tools that need to apply
transformations across translation unit boundaries.

See tools/clang-check/ClangCheck.cpp for an example.

llvm-svn: 154008

the new Objective-C NSArray/NSDictionary/NSNumber literal syntax.

This introduces a new library, libEdit, which provides a new way to support
migration of code that improves on the original ARC migrator.  We now believe
that most of its functionality can be refactored into the existing libraries,
and thus this new library may shortly disappear.

llvm-svn: 152141

for this.

llvm-svn: 133104

llvm-svn: 132462

llvm-svn: 130581

layout.  :)

Rename the 'EntoSA' directories to 'StaticAnalyzer'.

Internally we will still use the 'ento' namespace
for the analyzer engine (unless there are further
sabre rattlings...).

llvm-svn: 122514

update Makefile.

llvm-svn: 122493

llvm-svn: 122421

r110903 introduced a dependency from Frontend to every library that
declared an Action by introducing Action references that previously
resided in the driver in the file ExecuteCompilerInvocation.cpp.
This patch moves ExecuteCompilerInvocation to a new library named
FrontendTool which is intended to bear these dependencies.

llvm-svn: 111873

llvm-svn: 111279

llvm-svn: 111265

Create a new Serialization module that contains all the PCH code, and will contain all the module code in the future. Update the Makefiles, CMake projects and the Xcode project. I hope I did everything right for Xcode. No functionality change.

llvm-svn: 111258

llvm-svn: 107327

 - This eliminates most dependencies on how Clang is installed relative to LLVM.

llvm-svn: 105637

(1) libAnalysis is a generic analysis library that can be used by
    Sema.  It defines the CFG, basic dataflow analysis primitives, and
    inexpensive flow-sensitive analyses (e.g. LiveVariables).

(2) libChecker contains the guts of the static analyzer, incuding the
    path-sensitive analysis engine and domain-specific checks.

Now any clients that want to use the frontend to build their own tools
don't need to link in the entire static analyzer.

This change exposes various obvious cleanups that can be made to the
layout of files and headers in libChecker.  More changes pending.  :)

This change also exposed a layering violation between AnalysisContext
and MemRegion.  BlockInvocationContext shouldn't explicitly know about
BlockDataRegions.  For now I've removed the BlockDataRegion* from
BlockInvocationContext (removing context-sensitivity; although this
wasn't used yet).  We need to have a better way to extend
BlockInvocationContext (and any LocationContext) to add
context-sensitivty.

llvm-svn: 94406

 - compiler-rt should be checked out into $LLVM_SRC_ROOT/projects/compiler-rt.

 - On Darwin, this will automatically build the runtime libraries clang needs
   into $OBJROOT/lib/clang/<version>/darwin/...

 - The mechanism can easily support other platforms, and can eventually support
   multiple platforms once clang has some kind of configure process (for
   specifying the desired targets).

 - Feedback on the approach is welcome.

llvm-svn: 93910

Its purpose is to provide the basic infrastructure for cross-translation-unit analysis like indexing, refactoring, etc.

Currently it is very "primitive" and with no type-names support. It can provide functionality like
"show me all references of this function from these translation units".

llvm-svn: 74802

llvm-svn: 65867

driver taking lib/Driver.

llvm-svn: 65811

llvm-svn: 54383

lib dir and move all the libraries into it.  This follows the main
llvm tree, and allows the libraries to be built in parallel.  The
top level now enforces that all the libs are built before Driver,
but we don't care what order the libs are built in.  This speeds
up parallel builds, particularly incremental ones.

llvm-svn: 48402

llvm-svn: 45415

llvm-svn: 36887

llvm-svn: 36332

This feature is needed in order to support shifts of more than 255 bits
on large integer types.  This changes the syntax for llvm assembly to
make shl, ashr and lshr instructions look like a binary operator:
   shl i32 %X, 1
instead of
   shl i32 %X, i8 1
Additionally, this should help a few passes perform additional optimizations.

llvm-svn: 33776

1. Remove the LLVM_DO_NOT_BUILD feature (not needed any more)
2. Ensure that lib/VMCore gets built first. This needs to be done because
   VMCore now uses tblgen to generate the Intrinsics header which are
   needed in other libraries. In parallel builds, this can cause problems.

llvm-svn: 28374

other dirs (for Intrinsics.gen).  :(

llvm-svn: 28372

llvm-svn: 17763

llvm-svn: 16352

llvm-svn: 11416

llvm-svn: 10686

llvm-svn: 9312

llvm-svn: 8739

llvm-svn: 8371

llvm-svn: 8018

system.

llvm-svn: 7014

llvm-svn: 3808