llvm-svn: 144112

which they do. This avoids all of the default argument promotions that
we (1) don't want, and (2) undo during that custom type checking, and
makes sure that we don't run into trouble during template
instantiation. Fixes PR11320.

llvm-svn: 144110

property attribute.

llvm-svn: 144078

The Neon load/store intrinsics need to be implemented as macros to avoid
hiding alignment attributes on the pointer arguments, and the macros can
only evaluate those pointer arguments once (in case they have side effects),
so it has been hard to get the right type checking for those pointers.
I tried various alternatives in the arm_neon.h header, but it's much more
straightforward to just check directly in Sema.

llvm-svn: 144075

Based on work by Dmitry Sokolov!

llvm-svn: 144072

Membarth, test case by myself.

llvm-svn: 144063

llvm-svn: 144060

later on, or we will end up with a redundant '__unsafe_unretained'.

llvm-svn: 144059

expression evaluation:
 - When folding a non-value-dependent expression, we may try to use the
   initializer of a value-dependent variable. If that happens, give up.
 - In C++98, actually check that a const, non-volatile DeclRefExpr inside an ICE
   is of integral or enumeration type (a reference isn't OK!)
 - In C++11, DeclRefExprs for objects of const literal type initialized with
   value-dependent expressions are themselves value-dependent.
 - So are references initialized with value-dependent expressions (though this
   case is missing from the C++11 standard, along with many others).

llvm-svn: 144056

doesn't duplicate, but they all surface as implicit
properties.  It's also a useful optimization to not
duplicate the implicit getter lookup.  So, trust the
getter lookup that was already done in these cases.

llvm-svn: 144031

initializer; all other constexpr variables are merely required to be
initialized. In particular, a user-provided constexpr default constructor can be
used for such initialization.

llvm-svn: 144028

default", make a note of which is used when creating the
initial declaration. Previously, we would wait until later to handle
default/delete as a definition, but this is too late: when adding the
declaration, we already treated the declaration as "user-provided"
when in fact it was merely "user-declared".

Fixes PR10861 and PR10442, along with a bunch of FIXMEs.

llvm-svn: 144011

llvm-svn: 143997

llvm-svn: 143985

function template instantiations. Fixes <rdar://problem/10398005> / PR11312.

llvm-svn: 143984

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

__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

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: 143922

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

core constant value down to an APValue.

llvm-svn: 143909

llvm-svn: 143906

partially undoes the revert in r143491, but does not introduce any new instances
of the underlying issue (which is not yet fixed) in code which does not use
the 'constexpr' keyword.

llvm-svn: 143905

llvm-svn: 143887

llvm-svn: 143886

llvm-svn: 143877

"XFAIL: msys" has no effect, due to XFAIL inspects triplet, and msys build does not use *-msys-* but *-mingw32.

llvm-svn: 143868

property references to use a new PseudoObjectExpr
expression which pairs a syntactic form of the expression
with a set of semantic expressions implementing it.
This should significantly reduce the complexity required
elsewhere in the compiler to deal with these kinds of
expressions (e.g. IR generation's special l-value kind,
the static analyzer's Message abstraction), at the lower
cost of specifically dealing with the odd AST structure
of these expressions.  It should also greatly simplify
efforts to implement similar language features in the
future, most notably Managed C++'s properties and indexed
properties.

Most of the effort here is in dealing with the various
clients of the AST.  I've gone ahead and simplified the
ObjC rewriter's use of properties;  other clients, like
IR-gen and the static analyzer, have all the old
complexity *and* all the new complexity, at least
temporarily.  Many thanks to Ted for writing and advising
on the necessary changes to the static analyzer.

I've xfailed a small diagnostics regression in the static
analyzer at Ted's request.

llvm-svn: 143867

path. That assumption should never have been true, but it was until
I fixed it. Now that its fixed, add a triple here to get correct
behavior even on Windows.

llvm-svn: 143863

llvm-svn: 143858

llvm-svn: 143857

and prevent the diagnostic preprocessor run from writing a depfile.

llvm-svn: 143846

Thanks to Peter for pointing out how easy this is to do. I'm now much
happier with this solution.

llvm-svn: 143842

edge cases and have better behavior. Specifically, we should actually
prefer the general '4.6' version string over the '4.6.1' string, as
'4.6.2' should be able to replace it without breaking rpaths or any
other place that these paths have been embedded. Debian-based
distributions are already using a path structure with symlinks to
achieve in-place upgrades for patch versions. Now our parsing reflects
this and we select the shorter paths instead of the longer paths.

A separate issue was that we would not parse a leading patch version
number even in the presence of a suffix. The above change makes this
more problematic as it would cause a suffix being added to make us treat
the entire thing as patch-version-agnostic, which it isn't. This changes
the logic to distinguish between '4.4.x' and 4.4.1-x', and retain that
the latter has *some* patch number information. Currently, we always
bias toward the shorter and more canonical version strings. If it
becomes important we can add more Debian like rules to produce sequences
such as '4.4.1b' > '4.4.1' > '4.4.1-rc3' > '4.4.1-rc2' > '4.4.1-pre5',
but I'm very doubtful this will ever matter or be desirable.

I've made the tests for this logic a bit more interesting, and added
some specific tests for logic that is now different.

llvm-svn: 143841

rather than presuming that it is 3.0. This is extra important as the
version should be 3.1, but CMake hasn't caught up with the times.
That'll be fixed in a separate commit.

llvm-svn: 143823

it the exact same way that the Clang code computes this path.

Hopefully with this, the MSVC bots will actually come back to life.

llvm-svn: 143807