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

This one was rolled back as follow-up to the failing commit.
Second try.

For the function declaration

auto foo5(Foo) -> Foo;
the parameter tokens were mapped to cursors representing the
FunctionDecl:

Keyword: "auto" [1:1 - 1:5] FunctionDecl=test5:1:6
Identifier: "test5" [1:6 - 1:11] FunctionDecl=test5:1:6
Punctuation: "(" [1:11 - 1:12] FunctionDecl=test5:1:6
Identifier: "X" [1:12 - 1:13] FunctionDecl=test5:1:6 // Ops, not a TypeRef
Punctuation: ")" [1:13 - 1:14] FunctionDecl=test5:1:6
Punctuation: "->" [1:15 - 1:17] FunctionDecl=test5:1:6
Identifier: "X" [1:18 - 1:19] TypeRef=struct X:7:8
Punctuation: ";" [1:19 - 1:20]

Fix this by ensuring that the trailing return type is not visited as
first.

Patch by Nikolai Kosjar.

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


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

This broke test/Index/opencl-types.cl on several buildbots:
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-lld/builds/3294
http://lab.llvm.org:8011/builders/clang-ppc64be-linux-multistage/builds/6498
http://lab.llvm.org:8011/builders/clang-ppc64le-linux-multistage/builds/5239

> [libclang] Support querying whether a declaration is invalid
>
> This is useful for e.g. highlighting purposes in an IDE.
>
> Patch by Nikolai Kosjar.
>
> Differential Revision: https://reviews.llvm.org/D40072

Also reverting follow-ups that otherwise caused conflicts for the
revert:

r321700 "Fix line endings."
r321701 "Fix more line endings."

r321698 "[libclang] Fix cursors for functions with trailing return type"
> For the function declaration
>
> auto foo5(Foo) -> Foo;
> the parameter tokens were mapped to cursors representing the
> FunctionDecl:
>
> Keyword: "auto" [1:1 - 1:5] FunctionDecl=test5:1:6
> Identifier: "test5" [1:6 - 1:11] FunctionDecl=test5:1:6
> Punctuation: "(" [1:11 - 1:12] FunctionDecl=test5:1:6
> Identifier: "X" [1:12 - 1:13] FunctionDecl=test5:1:6 // Ops, not a TypeRef
> Punctuation: ")" [1:13 - 1:14] FunctionDecl=test5:1:6
> Punctuation: "->" [1:15 - 1:17] FunctionDecl=test5:1:6
> Identifier: "X" [1:18 - 1:19] TypeRef=struct X:7:8
> Punctuation: ";" [1:19 - 1:20]
>
> Fix this by ensuring that the trailing return type is not visited as
> first.
>
> Patch by Nikolai Kosjar.
>
> Differential Revision: https://reviews.llvm.org/D40561

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

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

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

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

For the function declaration

auto foo5(Foo) -> Foo;
the parameter tokens were mapped to cursors representing the
FunctionDecl:

Keyword: "auto" [1:1 - 1:5] FunctionDecl=test5:1:6
Identifier: "test5" [1:6 - 1:11] FunctionDecl=test5:1:6
Punctuation: "(" [1:11 - 1:12] FunctionDecl=test5:1:6
Identifier: "X" [1:12 - 1:13] FunctionDecl=test5:1:6 // Ops, not a TypeRef
Punctuation: ")" [1:13 - 1:14] FunctionDecl=test5:1:6
Punctuation: "->" [1:15 - 1:17] FunctionDecl=test5:1:6
Identifier: "X" [1:18 - 1:19] TypeRef=struct X:7:8
Punctuation: ";" [1:19 - 1:20]

Fix this by ensuring that the trailing return type is not visited as
first.

Patch by Nikolai Kosjar.

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

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

This is useful for e.g. highlighting purposes in an IDE.

Patch by Nikolai Kosjar.

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

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

This is the follow up patch for rL319881 which introduced
the function but did not put it into .exports file.

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

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

Summary:
The diagnostic was mostly introduced in D38101 by me, as a reaction to wasting a lot of time, see [[ https://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20171009/206427.html | mail ]].
However, the diagnostic is pretty dumb. While it works with no false-positives,
there are some questionable cases that are diagnosed when one would argue that they should not be.

The common complaint is that it diagnoses the comparisons between an `int` and
`long` when compiling for a 32-bit target as tautological, but not when
compiling for 64-bit targets. The underlying problem is obvious: data model.
In most cases, 64-bit target is `LP64` (`int` is 32-bit, `long` and pointer are
64-bit), and the 32-bit target is `ILP32` (`int`, `long`, and pointer are 32-bit).

I.e. the common pattern is: (pseudocode)
```
#include <limits>
#include <cstdint>
int main() {
  using T1 = long;
  using T2 = int;

  T1 r;
  if (r < std::numeric_limits<T2>::min()) {}
  if (r > std::numeric_limits<T2>::max()) {}
}
```
As an example, D39149 was trying to fix this diagnostic in libc++, and it was not well-received.

This *could* be "fixed", by changing the diagnostics logic to something like
`if the types of the values being compared are different, but are of the same size, then do diagnose`,
and i even attempted to do so in D39462, but as @rjmccall rightfully commented,
that implementation is incomplete to say the least.

So to stop causing trouble, and avoid contaminating upcoming release, lets do this workaround:
* move these three diags (`warn_unsigned_always_true_comparison`, `warn_unsigned_enum_always_true_comparison`, `warn_tautological_constant_compare`) into it's own `-Wtautological-constant-in-range-compare`
* Disable them by default
* Make them part of `-Wextra`
* Additionally, give `warn_tautological_constant_compare` it's own flag `-Wtautological-type-limit-compare`.
  I'm not happy about that name, but i can't come up with anything better.

This way all three of them can be enabled/disabled either altogether, or one-by-one.

Reviewers: aaron.ballman, rsmith, smeenai, rjmccall, rnk, mclow.lists, dim

Reviewed By: aaron.ballman, rsmith, dim

Subscribers: thakis, compnerd, mehdi_amini, dim, hans, cfe-commits, rjmccall

Tags: #clang

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

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

variable is extern "C" in linkage calculations.


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

Fix and simplify handling of return type for (generic) lambda conversion function to function pointer.

Previously, we would:
 * compute the type of the conversion function and static invoker as a
   side-effect of template argument deduction for a conversion
 * re-compute the type as part of deduced return type deduction when building
   the conversion function itself

Neither of these turns out to be quite correct. There are other ways to reach a
declaration of the conversion function than in a conversion (such as an
explicit call or friend declaration), and performing auto deduction causes the
function type to be rebuilt in the context of the lambda closure type (which is
different from the context in which it originally appeared, resulting in
spurious substitution failures for constructs that are valid in one context but
not the other, such as the use of an enclosing class's "this" pointer).

This patch switches us to use a different strategy: as before, we use the
declared type of the operator() to form the type of the conversion function and
invoker, but we now populate that type as part of return type deduction for the
conversion function. And the invoker is now treated as simply being an
implementation detail of building the conversion function, and isn't given
special treatment by template argument deduction for the conversion function
any more.


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

This addresses an issue introduced in r183451: since
`removePiecesWithInvalidLocations` is called *after* `adjustCallLocations`,
it is not necessary, and in fact harmful, to have this assertion in
adjustCallLocations.

Addresses rdar://36170689

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

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

Fixes verifier errors with Windows EH and OpenMP, which injects a
terminate scope around parallel blocks.

Fixes PR35778

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

- Fix formatting issue due to hyphenated terms at line breaks.
- Fix typo

This patch was made by Craig Flores

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


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

- Fix incorrect wording in various intrinsic descriptions. Previously the descriptions used "low-order" and "high-order" when the intended meaning was "even-indexed" and "odd-indexed".

This patch was made by Craig Flores

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


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

- Fixed innaccurate instruction mappings for various intrinsics.
- Fixed description of NaN handling in comparison intrinsics.
- Unify description of _mm_store_pd1 to match _mm_store1_pd.
- Fix incorrect wording in various intrinsic descriptions. Previously the descriptions used "low-order" and "high-order" when the intended meaning was "even-indexed" and "odd-indexed".
- Fix typos.
- Add missing italics command (\a) for params and fixed some parameter spellings.

This patch was made by Craig Flores

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


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

The way to fix an undefined-template warning is to add lines to the header file that defines the template pattern. We should suppress the warnings when the template pattern is in a system header because we don't expect users to edit those.


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

rdar://problem/33251668

Reviewers: arphaman, ahatanak

Reviewed By: arphaman

Subscribers: ptitei, cfe-commits

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


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

This reverts r321645.

I missed a compiler-rt test that needs updating.

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

Summary:
The C++ Itanium ABI says:
No cookie is required if the new operator being used is ::operator new[](size_t, void*).

We should only avoid poisoning the cookie if we're calling this
operator, not others. This is dealt with before the call to
InitializeArrayCookie.

Reviewers: rjmccall, kcc, rsmith

Subscribers: cfe-commits

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

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

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

  - reverts r321622, r321625, and r321626.
  - the use of bit-fields is still resulting in warnings - even though we can use static-asserts to harden the code and ensure the bit-fields are wide enough.  The bots still complain of warnings being seen.
  - to silence the warnings requires specifying the bit-fields with the underlying enum type (as opposed to the enum type itself), which then requires lots of unnecessary static casts of each enumerator within DeclSpec to the underlying-type, which even though could be seen as implementation details, it does hamper readability - and given the additional litterings, makes me question the value of the change.

So in short - I give up (for now at least).  

Sorry about the noise.

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

tools/clang/lib/Sema/DeclSpec.cpp: In member function 'void clang::DeclSpec::Finish(clang::Sema&, const clang::PrintingPolicy&)':
tools/clang/lib/Sema/DeclSpec.cpp:1116:8: error: could not convert 'clang::DeclSpec::TSW_unspecified' from 'const TSW {aka const clang::TypeSpecifierWidth}' to 'int'
tools/clang/lib/Sema/DeclSpec.cpp:1117:8: error: could not convert 'clang::DeclSpec::TSW_short' from 'const TSW {aka const clang::TypeSpecifierWidth}' to 'int'
tools/clang/lib/Sema/DeclSpec.cpp:1118:8: error: could not convert 'clang::DeclSpec::TSW_longlong' from 'const TSW {aka const clang::TypeSpecifierWidth}' to 'int'
tools/clang/lib/Sema/DeclSpec.cpp:1128:8: error: could not convert 'clang::DeclSpec::TSW_long' from 'const TSW {aka const clang::TypeSpecifierWidth}' to 'int'

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

  - bots were complaining that the bit-field width was less than the width of the underlying type (note, underlying types of enums can not be bit-fields)
  - add static_asserts for TSS and TSW to ensure that the bit-fields can hold all the enumerators - and add comments next to the last enumerator warning not to reorder.

See https://reviews.llvm.org/rC321622 for the patch that introduced the warnings.

  

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

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

[NFC] Modernize enums TypeSpecifierWidth, TypeSpecifierSign & TypeSpecifierType into scoped enums with underlying types.
  - Since these enums are used as bit-fields - for the bit-fields to be interpreted as unsigned, the underlying type must be specified as unsigned.

Previous failed attempt - wherein I did not specify an underlying type - was the sum of:
https://reviews.llvm.org/rC321614
https://reviews.llvm.org/rC321615



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

Clang is inherently a cross compiler and can generate code for any target
enabled during build. It however requires to specify many parameters in the
invocation, which could be hardcoded during configuration process in the
case of single-target compiler. The purpose of configuration files is to
make specifying clang arguments easier.

A configuration file is a collection of driver options, which are inserted
into command line before other options specified in the clang invocation.
It groups related options together and allows specifying them in simpler,
more flexible and less error prone way than just listing the options
somewhere in build scripts. Configuration file may be thought as a "macro"
that names an option set and is expanded when the driver is called.

Use of configuration files is described in `UserManual.rst`.

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


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

  - the enum changes to TypeSpecifierType are breaking some tests - and will require a more careful integration.

Sorry about rushing these changes - thought I could sneak them in prior to heading out for new years ;)


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

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

  

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

(Re-submission of D39937 with fixed tests.)

Adjust wording for const-qualification mismatch to be a little more clear.

Also add another diagnostic for a ref qualifier mismatch, which previously produced a useless error (this error path is simply very old; see rL119336):

Before:
  error: cannot initialize object parameter of type 'X0' with an expression of type 'X0'

After:
  error: 'this' argument to member function 'rvalue' is an lvalue, but function has rvalue ref-qualifier

Reviewers: aaron.ballman

Reviewed By: aaron.ballman

Subscribers: lebedev.ri, cfe-commits

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


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

A few tests need to be fixed



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

Summary:
Adjust wording for const-qualification mismatch to be a little more clear.

Also add another diagnostic for a ref qualifier mismatch, which previously produced a useless error (this error path is simply very old; see rL119336):

Before:
  error: cannot initialize object parameter of type 'X0' with an expression of type 'X0'

After:
  error: 'this' argument to member function 'rvalue' is an lvalue, but function has rvalue ref-qualifier

Reviewers: rsmith, aaron.ballman

Reviewed By: aaron.ballman

Subscribers: lebedev.ri, aaron.ballman, cfe-commits

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

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

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

Need to check targets in tests more carefully.



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

Clang is inherently a cross compiler and can generate code for any target
enabled during build. It however requires to specify many parameters in the
invocation, which could be hardcoded during configuration process in the
case of single-target compiler. The purpose of configuration files is to
make specifying clang arguments easier.

A configuration file is a collection of driver options, which are inserted
into command line before other options specified in the clang invocation.
It groups related options together and allows specifying them in simpler,
more flexible and less error prone way than just listing the options
somewhere in build scripts. Configuration file may be thought as a "macro"
that names an option set and is expanded when the driver is called.

Use of configuration files is described in `UserManual.rst`.

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


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

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

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