llvm-svn: 124646

compatible, not having the same type.

Fix rdar://8183908 in which compatible vector types weren't initialized properly leading to a crash.

llvm-svn: 124637

* llvm-link would complains about mismatched visibility
* If we produce a relocation with an available_externally, it is good to know that
it is hidden.

llvm-svn: 124633

CheckPointerTypesForAssignment.

llvm-svn: 124632

llvm-svn: 124620

working on canonical types already.

llvm-svn: 124618

the disappearance/alteration of files.

llvm-svn: 124616

logic.

llvm-svn: 124615

client. Fixes a libclang leak.

llvm-svn: 124614

ensue.

llvm-svn: 124613

automatic behavior (which is undesirable in a multithreaded context).

llvm-svn: 124612

Add -Wcustom-atomic-properties which warns if an atomic-by-default property has custom getter or setter.

The rationale is that it is highly likely that the user's getter/setter isn't atomically implemented. Off by default.
Addresses rdar://8782645.

-Wcustom-atomic-properties and -Wimplicit-atomic-properties are under the -Watomic-properties group.

llvm-svn: 124609

conversions (<rdar://problem/8592139>) for overload resolution. The
conversion ranking mirrors C++'s conversion ranking fairly closely,
except that we use a same pseudo-subtyping relationship employed by
Objective-C pointer assignment rather than simple checking
derived-to-base conversions. This change covers:

  - Conversions to pointers to a specific object type are better than
  conversions to 'id', 'Class', qualified 'id', or qualified 'Class'
  (note: GCC doesn't perform this ranking, but it matches C++'s rules
  for ranking conversions to void*).
  - Conversions to qualified 'id' or qualified 'Class' are better than
  conversions to 'id' or 'Class', respectively.
  - When two conversion sequences convert to the same type, rank the
  conversions based on the relationship between the types we're
  converting from. 
  - When two conversion sequences convert from the same non-id,
  non-Class type, rank the conversions based on the relationship of
  the types we're converting to. (note: GCC allows this ranking even
  when converting from 'id', which is extremeley dangerous).

llvm-svn: 124591

llvm-svn: 124585

allow ref-qualifiers on function types used as template type
arguments. GNU actually allows cv-qualifiers on function types in many
places where it shouldn't, so we currently categorize this as a GNU
extension.

llvm-svn: 124584

llvm-svn: 124582

llvm-svn: 124581

Fix the diagnostic when we are shadowing an external variable and there exists a locally scoped extern with the same name.

llvm-svn: 124580

llvm-svn: 124579

llvm-svn: 124578

Fixes rdar://8736362.

llvm-svn: 124577

Error for use of field from anonymous struct or union should say "invalid use of nonstatic data member"
not "call to non-static member function without an object argument".

llvm-svn: 124576

Allow taking the address of such a field for a pointer-to-member constant. Fixes rdar://8818236.

llvm-svn: 124575

This fixes a few compile errors when parsing <regex> from MSVC 2008 with clang.

llvm-svn: 124573

current translation unit as available_externally. 

This helps devirtualize the second example in PR3100, comment 18:

struct S { S() {}; virtual void xyzzy(); };
inline void foo(S *s) { s->xyzzy(); }
void bar() { S s; foo(&s); }

This involved four major changes:

1. In DefineUsedVTables, always mark virtual member functions as referenced for
   non-template classes and class template specializations.
2. In CodeGenVTables::ShouldEmitVTableInThisTU return true if optimizations are
   enabled, even if the key function is not implemented in this translation 
   unit. We don't ever do this for code compiled with -fapple-kext, because we
   don't ever want to devirtualize virtual member function calls in that case.
3. Give the correct linkage for vtables where the key function is not defined.
4. Update the linkage for RTTI structures when necessary.

llvm-svn: 124565

invocation. 

This mimics what gcc does and fixes libtool check for libraries.

llvm-svn: 124558

llvm-svn: 124554

When emitting RTTI for a non-class type, compute the visibility of the RTTI data based on the explicit visibility of the type.

llvm-svn: 124553

llvm-svn: 124551

llvm-svn: 124550

Set the visibility for typeinfo names.

llvm-svn: 124548

Change CodeGenModule::setTypeVisibility to take a TypeVisibilityKind enum instead of an "IsForRTTI" flag.

llvm-svn: 124546

llvm-svn: 124542

llvm-svn: 124541

llvm-svn: 124540

Make emitting a VTT a two-step process, much like emitting a VTable. You first get the address of the VTT, and then pass it to EmitVTTDefinition.

llvm-svn: 124539

llvm-svn: 124538

Add a new function, to be used by CGRTTI, CGVTables and CGVTT (which each has their own copy of this code).

llvm-svn: 124537

llvm-svn: 124536

llvm-svn: 124529