skip the x86_64 version for mingw32 and win32.

llvm-svn: 164977

llvm-svn: 164971

32bit and 64bit version of modern translator.
// rdar://12189793

llvm-svn: 164970

Fix treatment of case which came up on std-proposals@: 'void' is permitted in core constant expressions, despite not being a literal type.

llvm-svn: 164968

representation. Fix crash if it appears in the return type of a member function
definition.

llvm-svn: 164967

llvm-svn: 164961

By analogy with C structs, this seems to be legal, if probably discouraged.
It's only if the ivar is read from or written to that there's a problem.
Running a program that gets the "address" of an instance variable does in
fact return the offset when the base "object" is nil.

This isn't a full revert because r164442 includes some diagnostic tweaks
as well; those have been kept.

This partially reverts r164442 / 08965091770c9b276c238bac2f716eaa4da2dca4.

llvm-svn: 164960

This seems to be legal according to C11 6.5.3.2.

No functionality change.

llvm-svn: 164959

The original intent of this commit was to catch potential null dereferences
early, but it breaks the common "home-grown offsetof" idiom (PR13927):

 (((struct Foo *)0)->member - ((struct foo *)0))

As it turns out, this appears to be legal in C, per a footnote in
C11 6.5.3.2: "Thus, &*E is equivalent to E (even if E is a null pointer)".
In C++ this issue is still open:
  http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#232

We'll just have to make sure we have good path notes in the future.

This reverts r164441 / 9be016dcd1ca3986873a7b66bd4bc027309ceb59.

llvm-svn: 164958

care of comments by Dimitri and Doug.

llvm-svn: 164957

string in the config table so that it can be dumped as part of the 
config dumper.  Add a test to show that these options are sticking
and can be cross-checked using FileCheck.

llvm-svn: 164954

This is related to but not blocked by <rdar://problem/12137950>
("Return-by-value structs do not have associated regions")

This reverts r164875 / 3278d41e17749dbedb204a81ef373499f10251d7.

llvm-svn: 164952

-Allow Sema to do more processing on the initial Expr before checking it.
-Remove the special conditions in HandleExpr()
-Move the code so that only one call site is needed.
-Removed the function from Sema and only call it locally.
-Warn on potentially evaluated reference variables, not just casts to r-values.
-Update tests.

llvm-svn: 164951

Lookup can nevertheless find them due to the serialized lookup table.
For instance when reading a template decl's templatedDecl, it will search for existing decls that it could be a redeclaration of, and find the half-read template decl.
Thus there is no point in asserting the names of decls.

llvm-svn: 164932

Don't require specializations (of existing and read template) to be unique.

llvm-svn: 164931

Also move one of them from grep to FileCheck.
Patch from Joey Gouly <joey.gouly@arm.com>!

llvm-svn: 164929

llvm-svn: 164928

Bring ASTReader and Writer into sync for the case where a canonical template specialization was written, which is non-canonical at the time of reading: force the reading of the ClassTemplateDecl if it was written.
The easiest way out is to store whether the decl was canonical at the time of writing.
Add test.

llvm-svn: 164927

CodeGen: Copy tail padding when we're not dealing with a trivial copy assign or move assign operator.

This fixes a regression from r162254, the optimizer has problems reasoning
about the smaller memcpy as it's often not safe to widen a store but making it
smaller is.

llvm-svn: 164917

llvm-svn: 164908

llvm-svn: 164907

use it to suggest appropriate macro for __attribute__((deprecated)) in
-Wdocumentation-deprecated-sync.

llvm-svn: 164892

llvm-svn: 164879

This reverts commit 6f61df3e7256413dcb99afb9673f4206e3c4992c.

llvm-svn: 164877

This reverts commit 0006ba445962621ed82ec84400a6b978205a3fbc.

llvm-svn: 164876

This reverts commit 580cd17f256259f39a382e967173f34d68e73859.

llvm-svn: 164875

the validation occurred.

The original implementation was pessimistic - we assumed that ivars
which escape are invalidated. This version is optimistic, it assumes
that the ivars will always be explicitly invalidated: either set to nil
or sent an invalidation message.

llvm-svn: 164868

observe their addresses (taking their address gives the vtable slot) so we are
free to merge their definitions.

llvm-svn: 164864

Summary:
When issuing a diagnostic message for the -Wimplicit-fallthrough diagnostics, always try to find the latest macro, defined at the point of fallthrough, which is immediately expanded to "[[clang::fallthrough]]", and use it's name instead of the actual sequence.

Known issues: 
  * uses PP.getSpelling() to compare macro definition with a string (anyone can suggest a convenient way to fill a token array, or maybe lex it in runtime?);
  * this can be generalized and used in other similar cases, any ideas where it should reside then?

Reviewers: doug.gregor, rsmith

Reviewed By: rsmith

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D50

llvm-svn: 164858

New output:
  warning: weak property may be unpredictably set to nil
  note: property declared here
  note: assign the value to a strong variable to keep the object alive
        during use

<rdar://problem/12277204>

llvm-svn: 164857

Like properties, loading from a weak ivar twice in the same function can
give you inconsistent results if the object is deallocated between the
two loads. It is safer to assign to a strong local variable and use that.

Second half of <rdar://problem/12280249>.

llvm-svn: 164855

The motivating example:

if (self.weakProp)
  use(self.weakProp);

As with any non-atomic test-then-use, it is possible a weak property to be
non-nil at the 'if', but be deallocated by the time it is used. The correct
way to write this example is as follows:

id tmp = self.weakProp;
if (tmp)
  use(tmp);

The warning is controlled by -Warc-repeated-use-of-receiver, and uses the
property name and base to determine if the same property on the same object
is being accessed multiple times. In cases where the base is more
complicated than just a single Decl (e.g. 'foo.bar.weakProp'), it picks a
Decl for some degree of uniquing and reports the problem under a subflag,
-Warc-maybe-repeated-use-of-receiver. This gives a way to tune the
aggressiveness of the warning for a particular project.

The warning is not on by default because it is not flow-sensitive and thus
may have a higher-than-acceptable rate of false positives, though it is
less noisy than -Wreceiver-is-weak. On the other hand, it will not warn
about some cases that may be legitimate issues that -Wreceiver-is-weak
will catch, and it does not attempt to reason about methods returning weak
values.

Even though this is not a real "analysis-based" check I've put the bug
emission code in AnalysisBasedWarnings for two reasons: (1) to run on
every kind of code body (function, method, block, or lambda), and (2) to
suggest that it may be enhanced by flow-sensitive analysis in the future.

The second (smaller) half of this work is to extend it to weak locals
and weak ivars. This should use most of the same infrastructure.

Part of <rdar://problem/12280249>

llvm-svn: 164854

struct assignment.

llvm-svn: 164853

record, skip at least one element from the InitListExpr to avoid an infinite
loop if we're initializing an array of unknown bound.

llvm-svn: 164851

now be printed with highlighting.

llvm-svn: 164843

llvm-svn: 164841

use the integrated pre-processor, preprocess in objective-c++ mode. 
// rdar://12189793.

llvm-svn: 164836

Previously the analyzer treated all inlined constructors like lvalues,
setting the value of the CXXConstructExpr to the newly-constructed
region. However, some CXXConstructExprs behave like rvalues -- in
particular, the implicit copy constructor into a pass-by-value argument.
In this case, we want only the /contents/ of a temporary object to be
passed, so that we can use the same "copy each argument into the
parameter region" algorithm that we use for scalar arguments.

This may change when we start modeling destructors of temporaries,
but for now this is the last part of <rdar://problem/12137950>.

llvm-svn: 164830

An rvalue has no address, but calling a C++ member function requires a
'this' pointer. This commit makes the analyzer create a temporary region
in which to store the struct rvalue and use as a 'this' pointer whenever
a member function is called on an rvalue, which is essentially what
CodeGen does.

More of <rdar://problem/12137950>. The last part is tracking down the
C++ FIXME in array-struct-region.cpp.

llvm-svn: 164829

Struct rvalues are represented in the analyzer by CompoundVals,
LazyCompoundVals, or plain ConjuredSymbols -- none of which have associated
regions. If the entire structure is going to persist, this is not a
problem -- either the rvalue will be assigned to an existing region, or
a MaterializeTemporaryExpr will be present to create a temporary region.
However, if we just need a field from the struct, we need to create the
temporary region ourselves.

This is inspired by the way CodeGen handles calls to temporaries;
support for that in the analyzer is coming next.

Part of <rdar://problem/12137950>

llvm-svn: 164828