- also replace direct equality checks against the ConstantEvaluated enumerator  with isConstantEvaluted(), in anticipation of adding finer granularity to the various ConstantEvaluated contexts and reinstating certain restrictions on where lambda expressions can occur in C++17.

- update the clang tablegen backend that uses these Enumerators, and add the relevant scope where needed.


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

Correct class-template deprecation behavior

Based on the comment in the test, and my reading of the standard, a deprecated warning should be issued in the following case:
template<typename T> [[deprecated]] class Foo{}; Foo<int> f;

This was not the case, because the ClassTemplateSpecializationDecl creation did not also copy the deprecated attribute.

Note: I did NOT audit the complete set of attributes to see WHICH ones should be copied, so instead I simply copy ONLY the deprecated attribute.

Previous DiffRev: https://reviews.llvm.org/D27486, was reverted.
This patch fixes the issues brought up here by the reverter: https://reviews.llvm.org/rL298410

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


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

This reverts commit r298410 (which produces incorrect warnings, see
comments on https://reviews.llvm.org/rL298410).

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

Based on the comment in the test, and my reading of the standard, a deprecated warning should be issued in the following case:
template<typename T> [[deprecated]] class Foo{}; Foo<int> f;

This was not the case, because the ClassTemplateSpecializationDecl creation did not also copy the deprecated attribute.

Note: I did NOT audit the complete set of attributes to see WHICH ones should be copied, so instead I simply copy ONLY the deprecated attribute.

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


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

Improve workaround for Sphinx's lack of support for command line options containing '+', '.' etc. to be more stable as the set of options changes.


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

and generate documentation for all (non-hidden) options supported by the
'clang' driver.


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

Summary:
This patch changes TableGen-generated code in AttrPCHRead to call functions on
ASTRecordReader, instead of passing separate parameters to ASTReader. This is a
follow-up to r290217.

Reviewers: rsmith

Subscribers: cfe-commits

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

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

Summary:
When Sema looks up an attribute name, it strips off leading and trailing
"__" if the attribute is GNU-style.  That is, __attribute__((foo)) and
__attribute__((__foo__)) are equivalent.

This is only true for GNU-style attributes.  In particular,
__declspec(__foo__) is not equivalent to __declspec(foo), and Sema
respects this difference.

This patch fixes TableGen to match Sema's behavior.  The spelling
'GNU<"__foo__">' should be normalized to 'GNU<"foo">', but
'Declspec<"__foo__">' should not be changed.

This is necessary to make CUDA compilation work on Windows, because e.g.
the __device__ attribute is spelled __declspec(__device__).

Attr.td does not contain any Declspec spellings that start or end with
"__", so this change should not affect any other attributes.

Reviewers: rnk

Subscribers: cfe-commits, tra

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

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

This diff replaces --driver-mode=cpp in
utils/perf-training/order-files.lit.cfg and
utils/perf-training/lit.cfg with --driver-mode=g++.
clang --driver-mode=cpp will call the preprocessor and will not
trigger compilation.

Differential revision: https://reviews.llvm.org/D28269


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

This diff fixes the clean build of the target generate-order-file.
In llvm/tools/clang/CMakeLists.txt 
add_subdirectory(utils/perf-training) should go after the block where 
the value of the variable CLANG_ORDER_FILE is set - otherwise 
(tested with cmake's version 3.6.2) the arguments of perf-helper.py gen-order-file
will be ill-formed (CLANG_ORDER_FILE will be empty).

Differential revision: https://reviews.llvm.org/D28153


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

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

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

We should complain about the following:

```
void foo() __attribute__((unavailable("a", "b")));
```

Instead, we currently just ignore "b". (...We also end up ignoring "a",
because we assume elsewhere that this attribute can only have 1 or 0
args.)

This happens because `unavailable` has a fake enum arg, and
`AttributeList::{getMinArgs,getMaxArgs}` include fake args in their
counts.


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

Primarily: try to use DenseSet<StringRef> instead of
std::set<std::string>, and use pretty range algos where we can.

Small sizes were arbitrarily chosen.


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

This preparation to remove SetVector.h dependency on SmallSet.h.


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

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

It has been unmaintained for a while (last change was more than four
years ago), and it appears not widely used.
By now there are multiple well-maintained alternatives (emacs-ycmd,
atuo-complete-clang), and if users try to make this work they'll likely
have a bad user experience.

Reasoning and problems pointed out by Philipp Stephani.

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

The core of the change is supposed to be NFC, however it also fixes
what I believe was an undefined behavior when calling:

 va_start(ValueArgs, Desc);

with Desc being a StringRef.

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

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

- Use defvar to declare variables
- Don't use delete-backward-char, which is for interactive use only

Patch by Philipp Stephani

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

Treat lines in projectMap.csv that start with '#' as comments. This enables a
workflow where projects can be temporarily disabled with a comment describing
when they should be turned back on.

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

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

order in the .td file.


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

Update DiagnosticsReference and fix emitter to emit -Wpedantic diagnostics and groups in a deterministic order.


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

Ultimately it boiled down to adding a move constructor.

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281382 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

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

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

This is for attributes in []-delimited lists preceding a class, like e.g.
`[uuid("...")] class Foo {};`  Not used by anything yet, so no behavior change.
Part of https://reviews.llvm.org/D23895


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

Summary:
This attribute specifies expectations about the initialization of static and
thread local variables. Specifically that the variable has a
[constant initializer](http://en.cppreference.com/w/cpp/language/constant_initialization)
according to the rules of [basic.start.static]. Failure to meet this expectation
will result in an error.

Static objects with constant initializers avoid hard-to-find bugs caused by
the indeterminate order of dynamic initialization. They can also be safely
used by other static constructors across translation units.

This attribute acts as a compile time assertion that the requirements
for constant initialization have been met. Since these requirements change
between dialects and have subtle pitfalls it's important to fail fast instead
of silently falling back on dynamic initialization.

```c++
  // -std=c++14
  #define SAFE_STATIC __attribute__((require_constant_initialization)) static
  struct T {
    constexpr T(int) {}
    ~T();
  };
  SAFE_STATIC T x = {42}; // OK.
  SAFE_STATIC T y = 42; // error: variable does not have a constant initializer
  // copy initialization is not a constant expression on a non-literal type.
```
This attribute can only be applied to objects with static or thread-local storage
duration.

Reviewers: majnemer, rsmith, aaron.ballman

Subscribers: jroelofs, cfe-commits

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

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

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

Summary:
This attribute specifies expectations about the initialization of static and
thread local variables. Specifically that the variable has a
[constant initializer](http://en.cppreference.com/w/cpp/language/constant_initialization)
according to the rules of [basic.start.static]. Failure to meet this expectation
will result in an error.

Static objects with constant initializers avoid hard-to-find bugs caused by
the indeterminate order of dynamic initialization. They can also be safely
used by other static constructors across translation units.

This attribute acts as a compile time assertion that the requirements
for constant initialization have been met. Since these requirements change
between dialects and have subtle pitfalls it's important to fail fast instead
of silently falling back on dynamic initialization.

```c++
  // -std=c++14
  #define SAFE_STATIC __attribute__((require_constant_initialization)) static
  struct T {
    constexpr T(int) {}
    ~T();
  };
  SAFE_STATIC T x = {42}; // OK.
  SAFE_STATIC T y = 42; // error: variable does not have a constant initializer
  // copy initialization is not a constant expression on a non-literal type.
```
This attribute can only be applied to objects with static or thread-local storage
duration.

Reviewers: majnemer, rsmith, aaron.ballman

Subscribers: jroelofs, cfe-commits

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

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

The oneshot probe only gets executed the first time the probe is hit in the process. For order file generation this is really all we care about.

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

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

This reverts commit r277487.

Removing the probe predicate was a red herring. It results in more symbols being placed in the final order file, but they are symbols from outside the clang image.

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

Having the dtrace predicate setup to only show probes in clang filters out static initializers executed by dyld, which we do want included in the order files.

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

Dtrace probemod needs to be based on the first argument of the command, not the first argument of the args. This error was introduced a while back when I added support for skipping the driver and invoking cc1 directly.

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