llvm-svn: 143982

llvm-svn: 143980

-Move __strong/__weak added to a property type to the property attribute,
e.g.  "@property (assign) __weak Foo *prop;" --> "@property (weak) Foo *prop;"

-Remove (assign) in a property so that it becomes strong-by-default in ARC.

llvm-svn: 143979

llvm-svn: 143978

__int128_t and __uint128_t.  Short and unsigned short integer literals support
is only to work around a crasher as reported in PR11179 and will be removed
once Clang no longer builds short integer literals.

llvm-svn: 143977

to objects of classes that don't support ARC weak

llvm-svn: 143976

__weak is unsupported by the deployment target, since it is going to be
ignored anyway.

Makes it easier for incremental migration from GC.

llvm-svn: 143975

llvm-svn: 143974

llvm-svn: 143972

Fixes a self-host error.

llvm-svn: 143970

llvm-svn: 143969

the injected-class-name of a class (or class template) to the
declaration that results from substituting the given template
arguments. Previously, we would actually perform a substitution into
the injected-class-name type and then retrieve the resulting
declaration. However, in certain, rare circumstances involving
deeply-nested member templates, we would get the wrong substitution
arguments.

This new approach just matches up the declaration with a declaration
that's part of the current context (or one of its parents), which will
either be an instantiation (during template instantiation) or the
declaration itself (during the definition of the template). This is
both more efficient (we're avoiding a substitution) and more correct
(we can't get the template arguments wrong in the member-template
case). 

Fixes <rdar://problem/9676205>.

Reinstated, now that we have the fix in r143967.

llvm-svn: 143968

entering the context of a nested-name-specifier. Fixes
<rdar://problem/10397846>.

llvm-svn: 143967

llvm-svn: 143966

llvm-svn: 143965

and TargetLowering::BuildUDIV(). Fixes PR11283

llvm-svn: 143964

llvm-svn: 143962

llvm-svn: 143961

llvm-svn: 143960

This simplifies e.g:

if (Op.type == SCEVType::INT || Op.type == SCEVType::PARAM)

  to

if (Op.isConstant())

llvm-svn: 143959

llvm-svn: 143958

llvm-svn: 143925

llvm-svn: 143924

to fix the types section (all types, not just global types), and testcases.

The code to do the final emission is disabled by default.

llvm-svn: 143923

llvm-svn: 143922

the pubnames and pubtypes tables. LLDB can currently use this format
and a full spec is forthcoming and submission for standardization is planned.

A basic summary:

The dwarf accelerator tables are an indirect hash table optimized
for null lookup rather than access to known data. They are output into
an on-disk format that looks like this:

.-------------.
|  HEADER     |
|-------------|
|  BUCKETS    |
|-------------|
|  HASHES     |
|-------------|
|  OFFSETS    |
|-------------|
|  DATA       |
`-------------'

where the header contains a magic number, version, type of hash function,
the number of buckets, total number of hashes, and room for a special
struct of data and the length of that struct.

The buckets contain an index (e.g. 6) into the hashes array. The hashes
section contains all of the 32-bit hash values in contiguous memory, and
the offsets contain the offset into the data area for the particular
hash.

For a lookup example, we could hash a function name and take it modulo the
number of buckets giving us our bucket. From there we take the bucket value
as an index into the hashes table and look at each successive hash as long
as the hash value is still the same modulo result (bucket value) as earlier.
If we have a match we look at that same entry in the offsets table and
grab the offset in the data for our final match.

llvm-svn: 143921

llvm-svn: 143920

llvm-svn: 143919

llvm-svn: 143918

We don't actually need a separate flag for non-sysrooted paths as the
driver has to manage the sysroot anyways. The driver is not infrequently
adding paths to the header search based on their existence on the
filesystem. For that, it has to add the sysroot anyways, we should pass
it on down to CC1 already joined. More importantly, the driver cannot in
all cases distinguish between sysrooted paths and paths that are
relative to the Clang binary's installation directory. Essentially, we
always need to ignore the system root for these internal header search
options. It turns out in most of the places we were already providing
the system root in the driver, and then another one in CC1 so this fixes
several bugs.

llvm-svn: 143917

Test cases for this and all the rest of the port are still in the works,
but will wait for a fixed computer and post 3.0 merging...

llvm-svn: 143916

llvm-svn: 143915

llvm-svn: 143914

Colorize. (this is consistent with the coloring in diagnostics.html, but perhaps that's a bit out of date because it doesn't look like current clang behavior)

llvm-svn: 143913

It's still under construction but has enough info to be useful.

llvm-svn: 143912

llvm-svn: 143911

llvm-svn: 143910

core constant value down to an APValue.

llvm-svn: 143909

llvm-svn: 143908

llvm-svn: 143907