This mostly behaves cl.exe's behavior, even though clang-cl is stricter in some
corner cases and more lenient in others (see the included test).

To make the uuid declared previously here diagnostic work correctly, tweak
stripTypeAttributesOffDeclSpec() to keep attributes in the right order.

https://reviews.llvm.org/D24469


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281367 91177308-0d34-0410-b5e6-96231b3b80d8

implicit declarations of move operations, GCC 4.7 would find that SelectPiece
has neither a move constructor nor a copy constructor. The copy constructor was
(correctly) deleted because the class has a member of move-only type, and the
move constructor was (incorrectly, per current C++ rules) not provided because
the class has a copy-only base class (in turn because it explicitly declares a
destructor).


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281363 91177308-0d34-0410-b5e6-96231b3b80d8

For ObjC type parameter, we used to have TypedefType that is canonicalized to
id or the bound type. We can't represent "T <protocol>" and thus will lose
the type information in the following example:
@interface MyMutableDictionary<KeyType, ObjectType> : NSObject
- (void)setObject:(ObjectType)obj forKeyedSubscript:(KeyType <NSCopying>)key;
@end
MyMutableDictionary<NSString *, NSString *> *stringsByString;
NSNumber *n1, *n2;
stringsByString[n1] = n2;
--> no warning on type mismatch of the key.

To fix the problem, we introduce a new type ObjCTypeParamType that supports
a list of protocol qualifiers.

We create ObjCTypeParamType for ObjCTypeParamDecl when we create
ObjCTypeParamDecl. We also substitute ObjCTypeParamType instead of TypedefType
on an ObjCTypeParamDecl.

rdar://24619481
rdar://25060179

Differential Revision: http://reviews.llvm.org/D23080


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281358 91177308-0d34-0410-b5e6-96231b3b80d8

Fix target options for fp32/64-denormals so that

+fp64-denormals is set if fp64 is supported
-fp32-denormals if fp32 denormals is not supported, or -cl-denorms-are-zero is set
+fp32-denormals if fp32 denormals is supported and -cl-denorms-are-zero is not set

If target feature fp32/64-denormals is explicitly set, they will override default options and options deduced from -cl-denorms-are-zero.

Differential Revision: https://reviews.llvm.org/D24512

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281357 91177308-0d34-0410-b5e6-96231b3b80d8

We also need to add ObjCTypeParamTypeLoc. ObjCTypeParamType supports the
representation of "T <protocol>" where T is a type parameter. Before this,
we use TypedefType to represent the type parameter for ObjC.

ObjCTypeParamType has "ObjCTypeParamDecl *OTPDecl" and it extends from
ObjCProtocolQualifiers. It is a non-canonical type and is canonicalized
to the underlying type with the protocol qualifiers.

rdar://24619481
rdar://25060179

Differential Revision: http://reviews.llvm.org/D23079


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281355 91177308-0d34-0410-b5e6-96231b3b80d8

To construct the canonical type of ObjCTypeParamType, we need to apply
qualifiers on ObjCObjectPointerType. The updated applyObjCProtocolQualifiers
handles this case by merging the protocol lists, constructing a new
ObjCObjectType, then a new ObjCObjectPointerType.

rdar://24619481
rdar://25060179

Differential Revision: http://reviews.llvm.org/D24059


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281353 91177308-0d34-0410-b5e6-96231b3b80d8

Now ObjCObjectType extends from ObjCProtocolQualifiers. We save number of
protocols in ObjCProtocolQualifiers.

This is in preparation of adding a new type class ObjCTypeParamType that
can take protocol qualifiers.

rdar://24619481
rdar://25060179

Differential Revision: http://reviews.llvm.org/D23078


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281351 91177308-0d34-0410-b5e6-96231b3b80d8

The unit tests in this patch demonstrate the need to traverse template
parameter lists of DeclaratorDecls (e.g. VarDecls, CXXMethodDecls) and
TagDecls (e.g. EnumDecls, RecordDecls).

Fixes PR29042.
https://reviews.llvm.org/D24268

Patch from Lukasz
Łukasz Anforowicz <lukasza@chromium.org>!


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281345 91177308-0d34-0410-b5e6-96231b3b80d8

Reviewers: djasper

Subscribers: cfe-commits, klimek

Differential Revision: https://reviews.llvm.org/D24501

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281344 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281316 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281315 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281298 91177308-0d34-0410-b5e6-96231b3b80d8

Summary: This change adds "java" to the list of known extensions that clang-format supports.

Patch by Luis Hector Chavez

Reviewers: djasper

Subscribers: srhines, cfe-commits

Differential Revision: https://reviews.llvm.org/D24401

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281294 91177308-0d34-0410-b5e6-96231b3b80d8

Original commit message:

Add -fdiagnostics-show-hotness

Summary:
I've recently added the ability for optimization remarks to include the
hotness of the corresponding code region.  This uses PGO and allows
filtering of the optimization remarks by relevance.  The idea was first
discussed here:
http://thread.gmane.org/gmane.comp.compilers.llvm.devel/98334

The general goal is to produce a YAML file with the remarks.  Then, an
external tool could dynamically filter these by hotness and perhaps by
other things.

That said it makes sense to also expose this at the more basic level
where we just include the hotness info with each optimization remark.
For example, in D22694, the clang flag was pretty useful to measure the
overhead of the additional analyses required to include hotness.
(Without the flag we don't even run the analyses.)

For the record, Hal has already expressed support for the idea of this
patch on IRC.

Differential Revision: https://reviews.llvm.org/D23284

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281293 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281287 91177308-0d34-0410-b5e6-96231b3b80d8

In c++1z, static_assert is not required to have a StringLiteral message, where
previously it was required.  Update the AST Reader to be able to handle a
null StringLiteral.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281286 91177308-0d34-0410-b5e6-96231b3b80d8

Differential Revision: http://reviews.llvm.org/D20415

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281285 91177308-0d34-0410-b5e6-96231b3b80d8

This reverts commit r281276.

Many bots are failing.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281279 91177308-0d34-0410-b5e6-96231b3b80d8

We should be doing the same checks when a type is completed as we do
when a complete type is used during emission. Previously, we duplicated
the logic, and it got out of sync. This could be observed with
dllimported classes.

Also reduce a test case for this slightly.

Implementing review feedback from David Blaikie on r281057.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281278 91177308-0d34-0410-b5e6-96231b3b80d8

This patch makes us act more conservatively when trying to determine
the objectsize for an array at the end of an object. This is in
response to code like the following:

```
struct sockaddr {
  /* snip */
  char sa_data[14];
};

void foo(const char *s) {
  size_t slen = strlen(s) + 1;
  size_t added_len = slen <= 14 ? 0 : slen - 14;
  struct sockaddr *sa = malloc(sizeof(struct sockaddr) + added_len);
  strcpy(sa->sa_data, s);
  // ...
}
```

`__builtin_object_size(sa->sa_data, 1)` would return 14, when there
could be more than 14 bytes at `sa->sa_data`.

Code like this is apparently not uncommon. FreeBSD's manual even
explicitly mentions this pattern:
https://www.freebsd.org/doc/en/books/developers-handbook/sockets-essential-functions.html
(section 7.5.1.1.2).

In light of this, we now just give up on any array at the end of an
object if we can't find the object's initial allocation.

I lack numbers for how much more conservative we actually become as a
result of this change, so I chose the fix that would make us as
compatible with GCC as possible. If we want to be more aggressive, I'm
happy to consider some kind of whitelist or something instead.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281277 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
I've recently added the ability for optimization remarks to include the
hotness of the corresponding code region.  This uses PGO and allows
filtering of the optimization remarks by relevance.  The idea was first
discussed here:
http://thread.gmane.org/gmane.comp.compilers.llvm.devel/98334

The general goal is to produce a YAML file with the remarks.  Then, an
external tool could dynamically filter these by hotness and perhaps by
other things.

That said it makes sense to also expose this at the more basic level
where we just include the hotness info with each optimization remark.
For example, in D22694, the clang flag was pretty useful to measure the
overhead of the additional analyses required to include hotness.
(Without the flag we don't even run the analyses.)

For the record, Hal has already expressed support for the idea of this
patch on IRC.

Differential Revision: https://reviews.llvm.org/D23284

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281276 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281275 91177308-0d34-0410-b5e6-96231b3b80d8

Use range-based for loops to simplify the logic.  Add an explicit check for
MachO as the inline asm uses MachO specific directives.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281261 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281259 91177308-0d34-0410-b5e6-96231b3b80d8

definition as visible in the discarded definition's module, as we do for
other kinds of definition.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281258 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281241 91177308-0d34-0410-b5e6-96231b3b80d8

Fixed incorrect docs that referred to:
  objc_arc_weak_unavailable
when it should be:
  objc_arc_weak_reference_unavailable

Patch by: Sean McBride!


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281227 91177308-0d34-0410-b5e6-96231b3b80d8

Use (call-process region nil ...) instead of (point-min) so that the
call works in narrowed buffers.

Patch by Philipp Stephani, thank you!

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281203 91177308-0d34-0410-b5e6-96231b3b80d8

Summary: (Needed for D23353.)

Reviewers: alexfh

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D23842

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281200 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281198 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281197 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281195 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281194 91177308-0d34-0410-b5e6-96231b3b80d8

remark flags. For now I'm checking in a copy of the built documentation, but we
can replace this with a placeholder (as we do for the attributes reference
documentation) once we enable building this server-side.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281192 91177308-0d34-0410-b5e6-96231b3b80d8

MSVC emits /include directives in the .drective section for the
__dyn_tls_init function (decorated as ___dyn_tls_init@12 for 32-bit).

This fixes PR30347.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281189 91177308-0d34-0410-b5e6-96231b3b80d8

Refactor the assignment so that its much more clear that the if-clause contains
the lookup, and once cached is directly used.  NFC.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281150 91177308-0d34-0410-b5e6-96231b3b80d8

Without this, no tests fail if I remove the Diag() in the first if in
Sema::mergeMSInheritanceAttr().


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281136 91177308-0d34-0410-b5e6-96231b3b80d8

provided before trying to print it.

This fixes a segfault that occurs when function printPretty generated by
tablegen tries to print an optional argument of attribute
objc_bridge_related.

rdar://problem/28155469


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281132 91177308-0d34-0410-b5e6-96231b3b80d8

When deserializing ObjCInterfaceDecl with definition data, if we already have
a definition, try to keep the definition invariant; also pull in the
categories even if it is not what getDefinition returns (this effectively
combines categories).

rdar://27926200
rdar://26708823


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281119 91177308-0d34-0410-b5e6-96231b3b80d8

This is a spiritual re-commit of r201375 with only a brief delay
for upgrading the green dragon builders.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281094 91177308-0d34-0410-b5e6-96231b3b80d8