Modify the AttrBuilder class to store the attributes as a set instead of as a
bit mask. The Attribute class will represent only one attribute instead of a
collection of attributes.

This is the wave of the future!

llvm-svn: 171427

llvm-svn: 171426

This is just the output of sphinx-quickstart. Now all that is needed
to begin converting the analyzer docs to reST is the server-side setup.

The analyzer folks have asked me to keep this segregated from the other
clang docs since the analyzer is a logically separate project (and has
its own separate web page) even though it resides in the clang tree.

llvm-svn: 171425

This paves the way for converting the analyzer docs to Sphinx (by
setting up a nested Sphinx tree in this directory).

llvm-svn: 171424

Patch by Matthew King!

llvm-svn: 171423

llvm-svn: 171422

Patch by Will Dietz:

Minor touchup so the values of Offset/ID reflect their intention.
Previously, the sum (Offset+ID) was correct, but Offset/ID
individually were wrong.

Caught by investigating unsigned overflow reported by -fsanitize=integer.

llvm-svn: 171421

DAGCombiner::reduceBuildVecConvertToConvertBuildVec() was making two
mistakes:

1. It was checking the legality of scalar INT_TO_FP nodes and then generating
vector nodes.

2. It was passing the result value type to
TargetLoweringInfo::getOperationAction() when it should have been
passing the value type of the first operand.

llvm-svn: 171420

Even though we do have a `.. warning::` directive on the page, hopefully
having "In-Progress" in the title will help to condition people's
expectations a bit for when they run into the extremely bare-bones
release notes.

Also, when release season comes around again, maybe this will get
people's attention and avoid confusion about what is going into the
upcoming release, and what is for changes to trunk for the next version.

llvm-svn: 171419

The way Sphinx treats the "top-level" adornments is weird. It usually
uses the first top-level adornment as the page title, even if the
top-level adornment is just one "section" out of many (i.e. if the first
section is "Introduction", then it will make the page title be
"Introduction"). This behavior can be overriden by using an explicit
`..  title::` directive to set the title.

Since the Sphinx stylesheet that Clang is currently using ('haiku')
nicely puts the document title at the top of the page in the header,
this weird default behavior was resulting in a redundant "title" in the
body content. Getting rid of this redundant level of headings
effectively "exposes" one more level of heading from the stylesheet to
which now makes the real "sections" more distinct.

llvm-svn: 171417

Patch by Krzysztof Parzyszek!

llvm-svn: 171415

Patch by Michael M Kuperstein!

llvm-svn: 171414

Fixes Valgrind failures and removes bitwise operations that don't provide any benefit.
Valgrind failures reported by NAKAMURA Takumi.

llvm-svn: 171413

this, ensure we don't regress)

llvm-svn: 171412

llvm-svn: 171410

Language extensions are highly relevant to using clang as a compiler, so
move LanguageExtensions up into `Using Clang as a Compiler` on the
landing page.

The other documents from the now-gone `Language Extensions and Specs`
section on the landing page nicely fit hierarchically under
LanguageExtensions.rst, so put them under LanguageExtensions.rst's
toctree instead of on the landing page.

Impetus from Jordan Rose.

llvm-svn: 171409

llvm-svn: 171408

Spotted by Nikola Smiljanic.

llvm-svn: 171407

* Add support for specifying the alignment to use.
* Add the concept of native endianness. Used for unaligned native types.

The native alignment and read/write simplification is based on a patch by Richard Smith.

llvm-svn: 171406

This defeats the include-guard optimization when parsing.

llvm-svn: 171405

llvm-svn: 171402

Fixes:
- incorrect handling of multiple consecutive preprocessor directives
- crash when trying to right align the escpaed newline for a line that
  is longer than the column limit
- using only ColumnLimit-1 columns when layouting with escaped newlines
  inside preprocessor directives

llvm-svn: 171401

This fixes llvm.org/PR14786.

We will need to split there as a last resort, but that should be done
consistently independent of whether the type is a template type or not.

Before:
template <typename T>
aaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaaaaaaaa<T>
                    ::aaaaaaaaaa, aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);

After:
template <typename T>
aaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaa,
                    aaaaaaaaaaaaaaaaaaaaaaaaaa<T>::aaaaaaaaaa,
                    aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);

llvm-svn: 171400

- Fix a typo

llvm-svn: 171399

llvm-svn: 171398

llvm-svn: 171397

This fixes llvm.org/PR14687.
Also fixes segfault for lines starting with * or &.

Before:
a *~b;
*a = 1;  // <- this segfaulted

After:
a * ~b;
*a = 1;  // no segfault :-)

llvm-svn: 171396

This is the first step towards handling preprocessor directives. This
patch only fixes the most pressing issue, namely correctly escaping
newlines for tokens within a sequence of a preprocessor directive.

The next step will be to fix incorrect format decisions on #define
directives.

llvm-svn: 171393

This fixes llvm.org/PR14747.

Before: Type *A = (Type * ) P;
After:  Type *A = (Type *) P;
llvm-svn: 171390

This fixes llvm.org/PR14746.

Before: return - 1;
After:  return -1;
llvm-svn: 171389

This addresses llvm.org/PR14699

Before:
template <typename T>
    void looooooooooooooooooooooongFunction(int Param1, int Param2);
template <typename T> void looooooooooooooooooooongFunction(
    int Paaaaaaaaaaaaaaaaaaaaram1, int Paaaaaaaaaaaaaaaaaaaaram2);

After:
template <typename T>
void looooooooooooooooooooooongFunction(int Param1, int Param2);
template <typename T>
void looooooooooooooooooooongFunction(int Paaaaaaaaaaaaaaaaaaaaram1,
                                      int Paaaaaaaaaaaaaaaaaaaaram2);

llvm-svn: 171388

Before:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(
    aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa && aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);

After:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa &&
                                 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);

llvm-svn: 171386

llvm-svn: 171384

The linked Makefile is always up to date, so there's no point in having
a rotting list of libraries.

llvm-svn: 171383

llvm-svn: 171382

llvm-svn: 171381

llvm-svn: 171380

I clustered the docs by some intuitive/fuzzy notion of "similarity", and
some reasonable categories seemed to materialize. I tried to give the
clusters useful names, but you may want to take a look at the landing
page (<http://clang.llvm.org/docs/> for the lazy) and share your
thoughts.

I have to say, this small change really gives the docs a whole new life!
It makes our documentation quite a bit easier to navigate and scope out.

llvm-svn: 171379

llvm-svn: 171378

The core of this page is a set of pros/cons for the different ways to
use clang as a library. The title should reflect that the page helps you
choose between alternatives.

llvm-svn: 171377