The comment starting with "ParseDeclarationOrFunctionDefinition -" is above
a function called ParseDeclOrFunctionDefInternal.  Fix the comment by not
mentioning a function name, like the style guide requests nowadays.  No behavior
change.


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

We have invariants we like to guarantee for the
`ImplicitConversionKind`s in a `StandardConversionSequence`. These
weren't being upheld in code that r280553 touched, so Richard suggested
that we should fix that. See D24113.

I'm not entirely sure how to go about testing this, so no test case is
included. Suggestions welcome.


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

Clang tests for verifying the following syntaxes:
1. 0xNN and NNh are accepted as valid hexadecimal numbers, but 0xNNh is not.     
   0xNN and NNh may come with optional U or L suffix.                            
2. NNb is accepted as a valid binary (base-2) number, but 0bNN is not.           
   NNb may come with optional U or L suffix.                                     
                                                                                 
Differential Revision: https://reviews.llvm.org/D22112



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

This patch allows us to perform incompatible pointer conversions when
resolving overloads in C. So, the following code will no longer fail to
compile (though it will still emit warnings, assuming the user hasn't
opted out of them):

```
void foo(char *) __attribute__((overloadable));
void foo(int) __attribute__((overloadable));

void callFoo() {
  unsigned char bar[128];
  foo(bar); // selects the char* overload.
}
```

These conversions are ranked below all others, so:

  A. Any other viable conversion will win out
  B. If we had another incompatible pointer conversion in the example
     above (e.g. `void foo(int *)`), we would complain about
     an ambiguity.

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


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

Based on post-commit feedback over IRC with dblaikie, ideally, we should have a SmallVector constructor that accepts anything which can supply a range via ADL begin()/end() calls so that we can construct the SmallVector directly from anything range-like.

Since that doesn't exist right now, use a local variable instead of calling getAssocExprs() twice; NFC.



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

Summary:
When formatting source code that needs both requoting and reindentation,
merge the replacements to avoid erroring out for conflicting replacements.

Also removes the misleading Replacements parameter from the
TokenAnalyzer API.

Reviewers: djasper

Subscribers: klimek, cfe-commits

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

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

Summary:
Default imports appear outside of named bindings in curly braces:

  import A from 'a';
  import A, {symbol} from 'a';

Reviewers: djasper

Subscribers: klimek, cfe-commits

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

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

Summary:
User feedback is that they expect *all* imports to be sorted if any import was
affected by a change, not just imports up to the first non-affected line, as
clang-format currently does.

Reviewers: djasper

Subscribers: klimek, cfe-commits

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

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

Allow a C11 generic selection expression to select a function with the overloadable attribute as the result expression without crashing. This fixes PR30201.

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

look for a corresponding file, since we're not going to read it anyway.

No observable behavior change (though we now avoid pointlessly trying to stat
or open a file named "-").


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

during this function, and to avoid rolling back changes to the module manager's
data structures. Instead, we defer registering the module file until after we
have successfully finished loading it.


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

The class MismatchingNewDeleteDetector is in 
lib/Sema/SemaExprCXX.cpp inside the anonymous namespace.
This diff reorders the fields and removes the excessive padding.
Test plan: make -j8 check-clang

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


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

Summary:
We want wasm and asmjs to have matching ABIs, and right now asmjs uses
unsigned int for its size_t. This causes exported symbols in libcxx to
not match and can cause weird breakage where libcxx doesn't get linked
as a result.  Long-term we probably want wasm32, wasm64, and asmjs to
all use unsigned long, but that would cause unnecessary ABI churn for
asmjs so defer that until we can make all the ABI changes at once.

Patch by Jacob Gravelle

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

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

textually included, create an ImportDecl just as we would if we reached a
#include of any other modular header. This is necessary in order to correctly
determine the set of variables to initialize for an imported module.

This should hopefully make the modules selfhost buildbot green again.


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

This correctly connects compiler-rt-test-depends to test-depends and
check-compiler-rt to check-all.

Based on LLVM r280392, and Compiler-RT r280393.

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

This patch also introduces AnalysisOrderChecker which is intended for testing
of callback call correctness.

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


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

Some FileIDs that may be used by PlistDiagnostics were not added while building
a list of pieces. This caused assertion violation in GetFID() function.
This patch adds some missing FileIDs to avoid the assertion. It also contains
small refactoring of PlistDiagnostics::FlushDiagnosticsImpl().

Patch by Aleksei Sidorin, Ilya Palachev.

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


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

Since some profiling tools, such as gprof, ftrace, and uftrace, use
-pg option to generate a mcount function call at the entry of each
function. Function invocation can be detected by this hook function.

But mcount insertion is done before function inlining phase in clang,
sometime a function that already has a mcount call can be inlined in the
middle of another function.

This patch adds an attribute "counting-function" to each function
rather than emitting the mcount call directly in frontend so that this
attribute can be processed in backend. Then the mcount calls can be
properly inserted in backend after all the other optimizations are
completed.

Link: https://llvm.org/bugs/show_bug.cgi?id=28660

Reviewers: hans, rjmccall, hfinkel, rengolin, compnerd

Subscribers: shenhan, cfe-commits

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



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

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

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

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

declaration has a dependent type.

This fixes a bug where clang errors out on a valid code.

rdar://problem/28051467

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


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

C++ language standard is not C++98.


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

explicit specialization to a warning for C++98 mode (this is a defect report
resolution, so per our informal policy it should apply in C++98), and turn
the warning on by default for C++11 and later. In all cases where it fires, the
right thing to do is to remove the pointless explicit instantiation.


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

-fprofile-dir=path allows the user to specify where .gcda files should be
emitted when the program is run. In particular, this is the first flag that
causes the .gcno and .o files to have different paths, LLVM is extended to
support this. -fprofile-dir= does not change the file name in the .gcno (and
thus where lcov looks for the source) but it does change the name in the .gcda
(and thus where the runtime library writes the .gcda file). It's different from
a GCOV_PREFIX because a user can observe that the GCOV_PREFIX_STRIP will strip
paths off of -fprofile-dir= but not off of a supplied GCOV_PREFIX.

To implement this we split -coverage-file into -coverage-data-file and
-coverage-notes-file to specify the two different names. The !llvm.gcov
metadata node grows from a 2-element form {string coverage-file, node dbg.cu}
to 3-elements, {string coverage-notes-file, string coverage-data-file, node
dbg.cu}. In the 3-element form, the file name is already "mangled" with
.gcno/.gcda suffixes, while the 2-element form left that to the middle end
pass.


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

I tested the cases involving split-dwarf + gmlt +
no-split-dwarf-inlining, but didn't verify the simpler case without
gmlt.

The logic is, admittedly, a little hairy, but seems about as simple as I
could wrangle it.

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

specifications under -fno-exceptions, just as we don't diagnose other exception
specification mismatch errors.


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

indirect virtual bases. We don't need to be able to invoke such an assignment
operator from the derived class, and we shouldn't delete the derived assignment
op if we can't do so.


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

Classes with no virtual methods or whose virtual methods were all
inherited from virtual bases don't have a vfptr at offset zero. We were
crashing attempting to get the layout of that non-existent vftable.

We don't need any vshape info in this case because the debugger can
infer it from the base class information. The current class may not
introduce any virtual methods if we are in this situation.

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

This breaks chromium and its unclear if this is actually a modern convention.

This reverts SVN r280169.

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

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

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

The shape is really just the number of methods in the vftable, since we
don't support 16 bit far calls. All calls are near. Encode this number
in the size of the artificial __vtbl_ptr_type DIDerivedType that we
generate. For DWARF, this will be a normal pointer, but for codeview
this will be a wide pointer that gets pattern matched into a
VFTableShape record. Insert this type into the element list of all
dynamic classes when emitting CodeView, so that the backend can emit the
shape even if the vptr lives in a primary base class.

Fixes PR28150

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

The WebKit style page says to use nullptr, so this should be fine:
https://webkit.org/code-style-guidelines/

This fixes: llvm.org/PR30220

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

clang-format.py previously only worked in vim compiled against python2.

This patch adds the necessary syntax changes to make this work with vim
linked against python3, which is now shipped by default for at least Ubuntu16 and Arch.

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

Subscribers: cfe-commits


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

-ffast-math to CC1, but it included a wrong llvm regression tests which was
removed in r280065.  Although regression test noexceptionsfpmath.c makes sure
-fno-trapping-math ends up as a function attribute, this adds a test that
explicitly checks the driver output for -fno-trapping-math.


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

These clang tests check diagnostics from the backend by giving it an unvectorizable loop. This loop is now vectorized :/

Make it really unvectorizable by making it unprofitable to ifconvert.

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