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

We don't yet have a reduced testcase for this.


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

Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>

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

I discovered a case where the old algorithm would crash.  Instead of
trying to patch the algorithm, rewrite it.  The new algorithm operates
in three phases:
1. Find all paths to the subobject with the vptr.
2. Remove paths which are subsets of other paths.
3. Select the best path where 'best' is defined as introducing the most
   covariant overriders.  If two paths introduce different overriders,
   raise a diagnostic.

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

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

If a class is absent from instantiation and is incomplete, instantiate it as
an incomplete class thus avoiding compiler crash.

This change fixes PR18653.

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


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

This reverts commit r236422, effectively reapplying r236419.  ASan
helped me diagnose the problem: the non-leaking logic would free the
ASTConsumer before freeing Sema whenever `isCurrentASTFile()`, causing a
use-after-free in `Sema::~Sema()`.

This version unconditionally frees Sema and the ASTContext before
freeing the ASTConsumer.  Without the fix, these were either being freed
before the ASTConsumer was freed or leaked after, but they were always
spiritually released so this isn't really a functionality change.

I ran all of check-clang with ASan locally this time, so I'm hoping
there aren't any more problems lurking.

Original commit message:

    Try again to plug a leak that's been around since at least r128011
    after coming across the FIXME.  Nico Weber tried something similar
    in r207065 but had to revert in r207070 due to a bot failure.

    The build failure isn't visible anymore so I'm not sure what went
    wrong.  I'm doing this slightly differently -- when not
    -disable-free I'm still resetting the members (just not leaking
    them) -- so maybe it will work out this time?  Tests pass locally,
    anyway.

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

This fixes errors that occur if a path to the default compiler has spaces or if an argument with spaces is given to compiler (e.g. via -I). (http://reviews.llvm.org/D9357)

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

This reverts commit r236419, since it caused some bots to fail.  On:

http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/26124
http://bb.pgr.jp/builders/cmake-clang-x86_64-linux/builds/35086

these tests:

FAIL: Clang::import-decl.cpp
FAIL: Clang::floating-literal.c
FAIL: Clang::x86_64-linux-android.c

fail with this output:

Command Output (stderr):
--
Stack dump:
0.  Program arguments: /var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.obj/Release+Asserts/bin/clang -cc1 -internal-isystem /var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.obj/Release+Asserts/bin/../lib/clang/3.7.0/include -nostdsysteminc -ast-print -x ast -
/var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.obj/tools/clang/test/Modules/Output/import-decl.cpp.script: line 3:  9665 Segmentation fault      (core dumped) /var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.obj/Release+Asserts/bin/clang -cc1 -internal-isystem /var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.obj/Release+Asserts/bin/../lib/clang/3.7.0/include -nostdsysteminc -ast-print -x ast - < /var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.obj/tools/clang/test/Modules/Output/import-decl.cpp.tmp.ast
      9666 Done                    | /var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.obj/Release+Asserts/bin/FileCheck /var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.src/tools/clang/test/Modules/import-decl.cpp

--

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

Try again to plug a leak that's been around since at least r128011 after
coming across the FIXME.  Nico Weber tried something similar in r207065
but had to revert in r207070 due to a bot failure.

The build failure isn't visible anymore so I'm not sure what went wrong.
I'm doing this slightly differently -- when not -disable-free I'm still
resetting the members (just not leaking them) -- so maybe it will work
out this time?  Tests pass locally, anyway.

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

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

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

Before:
  void SomeFunction(vector< // break
      int> v);

After:
  void SomeFunction(vector< // break
                        int> v);

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

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

Switch PPCallbacks to take the new MacroDefinition instead of MacroDirective*, in order to preserve full information on module macro expansion.


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

clang::MacroDefinition now models the currently-defined value of a macro. The
previous MacroDefinition type, which represented a record of a macro definition
directive for a detailed preprocessing record, is now called MacroDefinitionRecord.


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

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

Using GetNumBytesInBuffer() assumes that the stream was not flushed between
the GetNumBytesInBuffer() calls, which may happen to be true or not,
depending on stream policy. tell() always reports the correct stream location.

Do note there are only two more uses of GetNumBytesInBuffer() in LLVM+clang, in
lib/MC/MCAsmStreamer.cpp and lib/Target/R600/InstPrinter/AMDGPUInstPrinter.cpp.
The former may be replacable by tell (needs testing) but while the later can
not be immediatly replaced by tell() as it uses the absolute value of
GetNumBytesInBuffer() rather than the real stream position. Both uses seems
to depend upon flush policy and thus may not work correctly depending upon the
stream behaviour.

Going forward, GetNumBytesInBuffer() should probably be protected, non-accessible
to raw_ostream clients.



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

OriginalColumn might not be set, so fall back to Location and SourceMgr
in case it is missing. Also initialize end column in case the token is
multi line, but it's the ` token itself that starts the multi line.

Patch by Martin Probst, thank you!

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

Parameters can have templated types and default values (= ...), which is
another location in which a template closer should be followed by
whitespace.

Patch by Martin Probst, thank you.

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

This test verifies that we can detect when the inheritance paths are
ambiguous due to covariant thunks, ensuring we don't regress PR16759.

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

The fact that PGO has a say in how these branch weights are determined
isn't interesting to most of CodeGen, so it makes more sense for this
API to be accessible via CodeGenFunction rather than CodeGenPGO.

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

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

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

The underlying problem is that there is currently no way to run
ObjCARCContract from llvm bitcode which is required by ObjC ARC.
This fix the problem by always enable ObjCARCContract pass if
optimization is enabled. The ObjCARC Contract pass has almost no
overhead on code that is not using ARC.

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

unmatched l_paren before setting the LHS to ExprError().

Fixes PR23285.

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

No functional change. This just makes it more obvious that the logic
in ComputeRegionCounts only depends on the counter map and local
state.

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

should not export the macro.

... at least, not unless we have local submodule visibility enabled.


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

This removes the RegionCounter class, which is only used as a helper
in teh ComputeRegionCounts stmt visitor. This class is just an extra
layer of abstraction that makes the code harder to follow at this
point, and removing it makes the logic quite a bit more direct.

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

"Don't crash" tests are silly, we might as well check that the
counters are consistent here.

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

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

The MSVC ABI has a bug introduced by appending to the end of vftables
which come from virtual bases: covariant thunks introduces via
non-overlapping regions of the inheritance lattice both append to the
same slot in the vftable.

It is possible to generate correct vftables in cases where one node in
the lattice completely dominates the other on the way to the base with
the vfptr; in all other cases, we must raise a diagnostic in order to
prevent the illusion that we succeeded in laying out the vftable.

This fixes PR16759.

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

A class might contain multiple ways of getting to a vbase, some of which
are virtual and other non-virtual.  It may be the case that a
non-virtual base contains an override of a method in a vbase.  This
means that we must carefully pick between a set of nvbases to determine
which is the best.

As a consequence, the findPathForVPtr algorithm is considerably simpler.

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

This flag specifies that the normal visibility rules should be used even for
local submodules (submodules of the currently-being-built module). Thus names
will only be visible if a header / module that declares them has actually been
included / imported, and not merely because a submodule that happened to be
built earlier declared those names. This also removes the need to modularize
bottom-up: textually-included headers will be included into every submodule
that includes them, since their include guards will not leak between modules.

So far, this only governs visibility of macros, not of declarations, so is not
ready for real use yet.


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

Cyclone actually supports all the goodies you'd expect to come with an AArch64
CPU, so it doesn't need its own clause. Also we should probably be testing
these clauses.

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

The LHS was already being corrected before being set to ExprError when
the RHS is invalid, but when it was present the middle of a ternary
expression would be dropped in the error paths.

Fixes PR23350.

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

Adjust the wording of the "brackets go after the unqualified-id" error message. It applies in cases that aren't unqualified-ids.


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

I'm dubious in weird behavior with CHECK-DAG.

Also, it won't "REQUIRE non-ms-sdk". All of RUNs have "-triple darwin".

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

This is needed to ensure the type casts are parsed properly. Fixes
PR23101.

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

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