Fix bug 12574 - Avoid infinite recursion in constructors and destructors when using Microsoft C++ ABI

llvm-svn: 155189

up an elaborated type specifier in a friend declaration, only look for type
declarations, per [basic.lookup.elab]p2. If we know that the redeclaration
lookup for a friend class template in a dependent context finds a non-template,
don't delay the diagnostic to instantiation time.

llvm-svn: 155187

llvm-svn: 155185

flags.  We have preprocessed source, so we don't need these.

No test case as it's fairly difficult to make the compiler crash on demand.  I'll
patiently wait for Ben to tell me how to do this in 2 lines of code.  :)
rdar://11283560

llvm-svn: 155180

is issued on weak property as receiver and not on
any other use of a weak property. // rdar://10225276

llvm-svn: 155169

removing a (new) duplicate test whose only difference was the tag type
being an enum instead of a struct.

llvm-svn: 155165

followed by an identifier as declaration specificer (except for ObjC).
This allows e.g. an out-of-line C++ member function definitions to be
recognized as functions and not as variable declarations if the type
name for the first parameter is not recognized as a type--say, when there
is a function name shadowing an enum type name and the parameter is
missing the "enum" keyword needed to distinguish the two.

Note that returning TPResult::Error() instead of TPResult::True()
appears to have the same end result, while TPResult::Ambiguous()
results in a crash.

llvm-svn: 155163

we generate correct code for both strong and weak atomic compare-exchanges, even
though we don't propagate to the IR enough information to generate optimal weak
compare-exchanges on architectures which support them.

llvm-svn: 155161

if receiver is a 'weak' property, by type or by attribute.
// rdar://10225276

llvm-svn: 155159

llvm-svn: 155155

llvm-svn: 155141

llvm-svn: 155140

llvm-svn: 155139

path-sensitive analysis like handling of trylock expressions.

llvm-svn: 155137

patch fixing writing a spurious 'static' into
the wrong place. // rdar://11275241

llvm-svn: 155130

which are checked in the parser, and analysis warnings that require the
full analysis.  This allows attribute syntax to be checked independently
of the full thread safety analysis.  Also introduces a new warning for the
case where a string is used as a lock expression; this allows the analysis
to gracefully handle expressions that would otherwise cause a parse error.

llvm-svn: 155129

llvm-svn: 155126

llvm-svn: 155108

llvm-svn: 155107

initialize references, create std::initializer_list objects, or call constructors.

llvm-svn: 155105

This fixes the included testcase and lets us simplify the code a bit. It
does require using mergeWithMin when merging class information to its
members. Expand the comments to explain why that works.

llvm-svn: 155103

an explicit default one. This means that with -fvisibility hidden we
now produce a hidden symbol for

template <typename T>
class DEFAULT foo {
  void bar() {}
};
class zed {};
template class foo<zed>;

This matches the behaviour of gcc 4.7.

llvm-svn: 155102

there is no need for mergeVisibily to ever increase the visibility. Not
doing so lets us replace an incorrect use of mergeVisibilityWithMin. The
testcase

struct HIDDEN RECT {
  int top;
};
DEFAULT RECT foo = {0};

shows that we should give preference to one of the attributes instead of
keeping the minimum. We still get this testcase wrong because mergeVisibily
handles two explicit visibilities incorrectly, but this is a step in the
right direction.

llvm-svn: 155101

llvm-svn: 155100

DHasExplicitVisibility. Simplify the code a bit.

llvm-svn: 155099

the current implementation this should be a nop as explicit visibility
takes precedence in mergeVisibility.

The location chosen is such that attributes checked above it can force
a symbol to be default. For example, an attribute is the variable or function.
Attributes checked after this point, can only make the visibility more
restrictive. An attribute in a type for example.

llvm-svn: 155098

currently a nop as those users are the first merge or are a merge
of a hidden explicit visibility, which always wins in the current
implementation.

llvm-svn: 155095

llvm-svn: 155088

llvm-svn: 155086

into the wrong place when rewriting a static function
which declares block literals. // rdar://11275241

llvm-svn: 155084

llvm-svn: 155082

specifications on member function templates of class templates and other such
nested beasties. Store the function template from which we are to instantiate
an exception specification rather than trying to deduce it. Plus some
additional test cases.

llvm-svn: 155076

r155047. See the LLVM log for the primary motivation:
  http://llvm.org/viewvc/llvm-project?rev=155047&view=rev

Primary commit r154828:
  - Several issues were raised in review, and fixed in subsequent
    commits.
  - Follow-up commits also reverted, and which should be folded into the
    original before reposting:
    - r154837: Re-add the 'undef BUILTIN' thing to fix the build.
    - r154928: Fix build warnings, re-add (and correct) header and
      license
    - r154937: Typo fix.

Please resubmit this patch with the relevant LLVM resubmission.

llvm-svn: 155048

property accessor (getter) missing, instead of crashing.
// rdar://11273060

llvm-svn: 155036

llvm-svn: 155011

llvm-svn: 155005

MIPS: Followup to r154606. Expand list of accepted MIPS target features in the MipsTargetInfoBase::setFeatureEnabled() routine.

llvm-svn: 154998

llvm-svn: 154997

at the command line.

llvm-svn: 154989

llvm-svn: 154986