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

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

Summary:
This is patch for bash completion for clang project.
We don't need space when completing options like "-stdlib=".

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

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

Ananas is a home-brew operating system, mainly for amd64 machines. After
using GCC for quite some time, it has switched to clang and never looked
back - yet, having to manually patch things is annoying, so it'd be much
nicer if this was in the official tree.

More information:

https://github.com/zhmu/ananas/
https://rink.nu/projects/ananas.html

Submitted by:	Rink Springer
Differential Revision:	https://reviews.llvm.org/D32936


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

Add warn_drv_object_size_disabled_O0 to the invalid command line
argument group. This should fix some bot failures:

  lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/13241/steps/test/logs/stdio

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

This check currently isn't able to diagnose any issues at -O0, not is it
likely to [1]. Disabling the check at -O0 leads to substantial compile
time and binary size savings.

[1] [cfe-dev] Disabling ubsan's object size check at -O0

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

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

This reverts commit r306137. It has problems on code like this:

  struct __declspec(dllimport) Foo {
    int a;
    int get_a() { return a; }
  };
  template <int (Foo::*Getter)()> struct HasValue {
    int operator()(Foo *p) { return (p->*Getter)(); }
  };
  int main() {
    Foo f;
    f.a = 3;
    int x = HasValue<&Foo::get_a>()(&f);
  }

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

This patch makes ubsan's nonnull return value diagnostics more precise,
which makes the diagnostics more useful when there are multiple return
statements in a function. Example:

1 |__attribute__((returns_nonnull)) char *foo() {
2 |  if (...) {
3 |    return expr_which_might_evaluate_to_null();
4 |  } else {
5 |    return another_expr_which_might_evaluate_to_null();
6 |  }
7 |} // <- The current diagnostic always points here!

runtime error: Null returned from Line 7, Column 2!
With this patch, the diagnostic would point to either Line 3, Column 5
or Line 5, Column 5.

This is done by emitting source location metadata for each return
statement in a sanitized function. The runtime is passed a pointer to
the appropriate metadata so that it can prepare and deduplicate reports.

Compiler-rt patch (with more tests): https://reviews.llvm.org/D34298

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

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

Summary:
Change data layout string so it would be compatible with MSP430 EABI.

Depends on D34561

Reviewers: asl, awygle

Reviewed By: asl

Subscribers: cfe-commits

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

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

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

(possible implicit) noexcept specifier

Throwing in the destructor is not good (C++11 change try to not allow see below).
 But in reality, those codes are exist.
C++11 [class.dtor]p3:

A declaration of a destructor that does not have an exception-specification is 
implicitly considered to have the same exception specification as an implicit 
declaration.

With this change, the application worked before may now run into runtime 
termination. My goal here is to emit a warning to provide only possible info to 
where the code may need to be changed.

First there is no way, in compile time to identify the “throw” really throw out 
of the function. Things like the call which throw out… To keep this simple, 
when “throw” is seen, checking its enclosing function(only destructor and 
dealloc functions) with noexcept(true) specifier emit warning.

Here is implementation detail:
A new member function CheckCXXThrowInNonThrowingFunc is added for class Sema 
in Sema.h. It is used in the call to both BuildCXXThrow and 
TransformCXXThrowExpr.

The function basic check if the enclosing function with non-throwing noexcept 
specifer, if so emit warning for it.

The example of warning message like:
k1.cpp:18:3: warning: ''~dependent_warn'' has a (possible implicit) non-throwing

    noexcept specifier. Throwing exception may cause termination.
        [-Wthrow-in-dtor]
        throw 1;
        ^

        k1.cpp:43:30: note: in instantiation of member function

        'dependent_warn<noexcept_fun>::~dependent_warn' requested here

        dependent_warn<noexcept_fun> f; // cause warning

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



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

We were already applying the same rules to dllimport function pointers.
David Majnemer added that logic back in r211677 to fix PR20130.  We
failed to extend that logic to non-virtual member function pointers,
which are basically function pointers in a struct with some extra
offsets.

Fixes PR33570.

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

Summary:
Add value completion support for options which are defined in
CC1Options.td, because we only handled options in Options.td.

Reviewers: ruiu, v.g.vassilev, teemperor

Subscribers: llvm-commits

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

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

This is useful when an upper limit on the cache size needs to be
controlled independently of the amount of the amount of free space.

One use case is a machine with a large number of cache directories
(e.g. a buildbot slave hosting a large number of independent build
jobs). By imposing an upper size limit on each cache directory,
users can more easily estimate the server's capacity.

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

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

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

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

Add missing -### to the driver to ensure that we dont try to run the
actual command.  The host may not support the IAS.  Should fix the SCEI
buildbots.

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

Currently, autocompleted options are displayed in the same order as we
wrote them in .td files. This patch sort them out in clang so that they
are sorted alphabetically. This should improve usability.

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

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

Restore the `-gz` option to the driver with some minor tweaks to handle
the additional case for `-Wa,--compress-debug-sections`.

This intends to make the compression of the debug information
controllable from the driver.  The following is the behaviour:

  -gz           enable compression (ambiguous for format, will default to zlib-gnu)
  -gz=none      disable compression
  -gz=zlib-gnu  enable compression (deprecated GNU style zlib compression)
  -gz=zlib      enable compression (zlib based compression)

Although -Wa,-compress-debug-sections works, it should be discouraged
when using the driver to invoke the assembler.  However, we permit the
assembler to accept the GNU as style argument --compress-debug-sections
to maintain compatibility.

Note, -gz/-gz= does *NOT* imply -g.  That is, you need to additionally
specific -g for debug information to be generated.

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

dependent initializer"

It caused buildbot failures such as this one:
http://bb.pgr.jp/builders/test-clang-msc-x64-on-i686-linux-RA/builds/3777/steps/test_clang/logs/Clang%20%3A%3A%20Index__ctor-init-source-loc.cpp


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

This commit fixes incorrect source positions of dependent c'tor initializers
like in the following code:

template<typename MyBase>
struct Derived: MyBase::InnerIterator
{

Derived() : MyBase::InnerIterator() {} /// This line is problematic: all positions point to InnerIterator and nothing points to MyBase
};

Patch by Serge Preis!

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


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

Summary:
This patch adds a `SortUsingDeclaration` style option and enables it for llvm
style.

Reviewers: klimek

Reviewed By: klimek

Subscribers: klimek

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

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

Summary:
This updates the format options documentation script to indent the
documentation of nested fields. The previous format caused some problems,
as when a bulleted list ends with a multiline comment. See the buildbot failure
http://lab.llvm.org:8011/builders/clang-sphinx-docs/builds/10020/steps/docs-clang-html/logs/stdio

Reviewers: djasper

Reviewed By: djasper

Subscribers: cfe-commits

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

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

Summary: Style documentation is generated automatically by `docs/tools/dump_format_style.py`. This hasn't been ran for a while.

Reviewers: djasper

Subscribers: cfe-commits, klimek

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

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

Summary:
Prior to this change, using `-fdiagnostics-show-hotness` with a sampling
profile specified via `-fprofile-sample-use=` would result in the Clang
frontend emitting a warning: "argument '-fdiagnostics-show-hotness' requires
profile-guided optimization information". Of course, a sampling profile
*is* profile-guided optimization information, so the warning is misleading.
Furthermore, despite the warning, hotness was displayed based on the data in
the sampling profile.

Prevent the warning from being emitted when a sampling profile is used, and
add a test that verifies this.

Reviewers: anemet, davidxl

Reviewed By: davidxl

Subscribers: danielcdh, cfe-commits

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

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

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

declarations that are owned but unconditionally visible.

This allows us to set declarations as visible even if they have a local owning
module, without losing information. In turn, that means that our Objective-C
support can keep on incorrectly assuming the "hidden" bit on the declaration is
the whole story with regard to name visibility. This will also be useful once
we support the C++ Modules TS export semantics.

Objective-C name visibility is still incorrect in any case where the "hidden"
bit is not the complete story: for instance, in Objective-C++ the set of
visible categories will be wrong during template instantiation, and with local
submodule visibility enabled it will be wrong when building modules. Fixing that
will require a major overhaul of how visibility is handled for Objective-C (and
particularly for categories).


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

Also, don't use the outdated lib32/lib64 naming of files
within the sysroot. The more modern/flexible approach
IIUC is to use seperate sysroots or /lib/<target-tripple>
and /include/<target-tripple>.

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

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

have attached an initializer to the in-class declaration. If so, include the
initializer in the update record for the instantiation.


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

The new compiler warning -Wunguarded-availability-new is a subset of
-Wunguarded-availability. It is on by default. It only warns about uses of APIs
that have been introduced in macOS >= 10.13, iOS >= 11, watchOS >= 4 and
tvOS >= 11. We decided to use this kind of solution as we didn't want to turn
on -Wunguarded-availability by default, because we didn't want our users to get
warnings about uses of old APIs in their existing projects.

rdar://31054725

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


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

of class template specializations

This commit fixes an issue where a forward declaration of a class template
specialization was not related to the base template. We need to relate even
forward declarations because specializations don't have to be defined.

rdar://32869409

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


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

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


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

We need to take type alignment padding into account whe computing physical
layouts.

The layout must be compatible with the input layout, offsets are defined in
terms of offsets within a packed struct which are computed in terms of the alloc
size of a type.

Usingthe store size we would insert padding for the following type for example:

struct {

  int3 v;
  long long l;
} __attribute((packed))

On x86-64 int3 is padded to int4 alignment. The swiftcc type would be
<{ <3 x float>, [4 x i8], i64 }> which is not compatible with <{ <3 x float>,
i64 }>.

The latter has i64 at offset 16 and the former at offset 20.

rdar://32618125

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

Done to remove noise from https://reviews.llvm.org/D32332 (and to make
this test more resilient to changes in general).


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

[preprocessor] Fix assertion hit when 'SingleFileParseMode' option is enabled and #if with an undefined identifier and without #else

'HandleEndifDirective' asserts that 'WasSkipping' is false, so switch to using 'FoundNonSkip' as the hint for 'SingleFileParseMode' to keep going with parsing.

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

If we want to make sure that a particular string is not in an output,
the regular way of doing it is to add `-NOT` prefix instead of checking
if FileCheck resulted in an error.

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

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

In running some internal vectorcall tests in 32 bit mode, we discovered that the 
behavior I'd previously implemented for x64 (and applied to x32) regarding the 
assignment of SSE registers was incorrect. See spec here: 
https://msdn.microsoft.com/en-us/library/dn375768.aspx

My previous implementation applied register argument position from the x64 
version to both. This isn't correct for x86, so this removes and refactors that 
section. Additionally, it corrects the integer/int-pointer assignments. Unlike 
x64, x86 permits integers to be assigned independent of position.

Finally, the code for 32 bit was cleaned up a little to clarify the intent, 
as well as given a descriptive comment.

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


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

Summary:
This is the same as Inline, except it does not imply all empty
functions are merged: with this style, empty functions are merged only
if they also match the 'inline' criteria (i.e. defined in a class).

This is helpful to avoid inlining functions in implementations files.

Reviewers: djasper, krasimir

Reviewed By: djasper

Subscribers: klimek, rengolin, cfe-commits

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

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

"specializationOf" relation if they pseudo-override a type in the base template

This commit fixes an issue where Xcode's renaming engine couldn't find the
reference to the second occurrence of "InnerClass" in this example:

template<typename T> struct Ts { template<typename U> struct InnerClass { }; };

template<> struct Ts<int> {
template<typename U> struct InnerClass; // This occurrence wasn't renamed
};

rdar://31884960

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


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

While a function body is being parsed, the function declaration is not considered
as a definition because it does not have a body yet. In some cases it leads to
incorrect interpretation, the case is presented in
https://bugs.llvm.org/show_bug.cgi?id=14785:
```
    template<typename T> struct Somewhat {
      void internal() const {}
      friend void operator+(int const &, Somewhat<T> const &) {}
    };
void operator+(int const &, Somewhat<char> const &x) { x.internal(); }
```
When statement `x.internal()` in the body of global `operator+` is parsed, the type
of `x` must be completed, so the instantiation of `Somewhat<char>` is started. It
instantiates the declaration of `operator+` defined inline, and makes a check for
redefinition. The check does not detect another definition because the declaration
of `operator+` is still not defining as does not have a body yet.

To solves this problem the function `isThisDeclarationADefinition` considers
a function declaration as a definition if it has flag `WillHaveBody` set.

This change fixes PR14785.

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

This is a recommit of 305379, reverted in 305381, with small changes.


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

Should fix buildbots that pass -Werror.

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