Enable -dump-deserialized-decls and -error-on-deserialized-decl for modules.

llvm-svn: 294359

Revert "Use filename in linemarker when compiling preprocessed source"

This reverts commit r293004 because it broke the buildbots with "unknown CPU"
errors. I tried to fix it in r293026, but that br

Revert "Use filename in linemarker when compiling preprocessed source"

This reverts commit r293004 because it broke the buildbots with "unknown CPU"
errors. I tried to fix it in r293026, but that broke on Green Dragon with this
kind of error:

error: expected string not found in input
// CHECK: l{{ +}}df{{ +}}*ABS*{{ +}}{{0+}}{{.+}}preprocessed-input.c{{$}}
^
<stdin>:2:1: note: scanning from here
/Users/buildslave/jenkins/sharedspace/incremental@2/clang-build/tools/clang/test/Frontend/Output/preprocessed-input.c.tmp.o: file format Mach-O 64-bit x86-64
^
<stdin>:2:67: note: possible intended match here
/Users/buildslave/jenkins/sharedspace/incremental@2/clang-build/tools/clang/test/Frontend/Output/preprocessed-input.c.tmp.o: file format Mach-O 64-bit x86-64

I suppose this means that llvm-objdump doesn't support Mach-O, so the test
should indeed check for linux (but not for x86). I'll leave it to someone that
knows better.

llvm-svn: 293032

show more ...

Use filename in linemarker when compiling preprocessed source

Summary:
Clang appears to always use name as specified on the command
line, whereas gcc uses the name as specified in the linemarker at

Use filename in linemarker when compiling preprocessed source

Summary:
Clang appears to always use name as specified on the command
line, whereas gcc uses the name as specified in the linemarker at the
first line when compiling a preprocessed source. This results mismatch
between two compilers in FILE symbol table entry. This patch makes clang
to resemble gcc's behavior in finding the original source file name and
use it as an input file name.

Even with this patch, values of FILE symbol table entry may still be
different because clang uses dirname+basename for the entry whlie gcc
uses basename only. I'll write a patch for that once this patch is
committed.

Reviewers: dblaikie, inglorion

Reviewed By: inglorion

Subscribers: inglorion, aprantl, bruno

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

llvm-svn: 293004

show more ...

Move Preprocessor over to std::shared_ptr rather than IntrusiveRefCntPtr

llvm-svn: 291166

[Frontend] Use vfs for directory iteration while searching PCHs. NFCI

Use the vfs lookup instead of real filesytem and handle the case where
-include-pch is a directory and this dir is searched for

[Frontend] Use vfs for directory iteration while searching PCHs. NFCI

Use the vfs lookup instead of real filesytem and handle the case where
-include-pch is a directory and this dir is searched for a PCH.

llvm-svn: 289459

show more ...

Reapply r276973 "Adjust Registry interface to not require plugins to export a registry"

This differs from the previous version by being more careful about template
instantiation/specialization in or

Reapply r276973 "Adjust Registry interface to not require plugins to export a registry"

This differs from the previous version by being more careful about template
instantiation/specialization in order to prevent errors when building with
clang -Werror. Specifically:
* begin is not defined in the template and is instead instantiated when Head
is. I think the warning when we don't do that is wrong (PR28815) but for now
at least do it this way to avoid the warning.
* Instead of performing template specializations in LLVM_INSTANTIATE_REGISTRY
instead provide a template definition then do explicit instantiation. No
compiler I've tried has problems with doing it the other way, but strictly
speaking it's not permitted by the C++ standard so better safe than sorry.

Original commit message:

Currently the Registry class contains the vestiges of a previous attempt to
allow plugins to be used on Windows without using BUILD_SHARED_LIBS, where a
plugin would have its own copy of a registry and export it to be imported by
the tool that's loading the plugin. This only works if the plugin is entirely
self-contained with the only interface between the plugin and tool being the
registry, and in particular this conflicts with how IR pass plugins work.

This patch changes things so that instead the add_node function of the registry
is exported by the tool and then imported by the plugin, which solves this
problem and also means that instead of every plugin having to export every
registry they use instead LLVM only has to export the add_node functions. This
allows plugins that use a registry to work on Windows if
LLVM_EXPORT_SYMBOLS_FOR_PLUGINS is used.

llvm-svn: 277806

show more ...

Revert r276973 "Adjust Registry interface to not require plugins to export a registry"

Buildbot failures when building with clang -Werror. Reverting while I try to
figure this out.

llvm-svn: 277008

Reapply r276856 "Adjust Registry interface to not require plugins to export a registry"

This version has two fixes compared to the original:
* In Registry.h the template static members are instanti

Reapply r276856 "Adjust Registry interface to not require plugins to export a registry"

This version has two fixes compared to the original:
* In Registry.h the template static members are instantiated before they are
used, as clang gives an error if you do it the other way around.
* The use of the Registry template in clang-tidy is updated in the same way as
has been done everywhere else.

Original commit message:

Currently the Registry class contains the vestiges of a previous attempt to
allow plugins to be used on Windows without using BUILD_SHARED_LIBS, where a
plugin would have its own copy of a registry and export it to be imported by
the tool that's loading the plugin. This only works if the plugin is entirely
self-contained with the only interface between the plugin and tool being the
registry, and in particular this conflicts with how IR pass plugins work.

This patch changes things so that instead the add_node function of the registry
is exported by the tool and then imported by the plugin, which solves this
problem and also means that instead of every plugin having to export every
registry they use instead LLVM only has to export the add_node functions. This
allows plugins that use a registry to work on Windows if
LLVM_EXPORT_SYMBOLS_FOR_PLUGINS is used.

llvm-svn: 276973

show more ...

Revert r276856 "Adjust Registry interface to not require plugins to export a registry"

This is causing a huge pile of buildbot failures.

llvm-svn: 276857

Adjust Registry interface to not require plugins to export a registry

Currently the Registry class contains the vestiges of a previous attempt to
allow plugins to be used on Windows without using BU

Adjust Registry interface to not require plugins to export a registry

Currently the Registry class contains the vestiges of a previous attempt to
allow plugins to be used on Windows without using BUILD_SHARED_LIBS, where a
plugin would have its own copy of a registry and export it to be imported by
the tool that's loading the plugin. This only works if the plugin is entirely
self-contained with the only interface between the plugin and tool being the
registry, and in particular this conflicts with how IR pass plugins work.

This patch changes things so that instead the add_node function of the registry
is exported by the tool and then imported by the plugin, which solves this
problem and also means that instead of every plugin having to export every
registry they use instead LLVM only has to export the add_node functions. This
allows plugins that use a registry to work on Windows if
LLVM_EXPORT_SYMBOLS_FOR_PLUGINS is used.

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

llvm-svn: 276856

show more ...

[NFC] Header cleanup

Summary: Removed unused headers, replaced some headers with forward class declarations

Patch by: Eugene <claprix@yandex.ru>

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

[NFC] Header cleanup

Summary: Removed unused headers, replaced some headers with forward class declarations

Patch by: Eugene <claprix@yandex.ru>

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

llvm-svn: 275882

show more ...

Make it possible for AST plugins to enable themselves by default

Currently when an AST plugin is loaded it must then be enabled by passing
-plugin pluginname or -add-plugin pluginname to the -cc1 co

Make it possible for AST plugins to enable themselves by default

Currently when an AST plugin is loaded it must then be enabled by passing
-plugin pluginname or -add-plugin pluginname to the -cc1 command line. This
patch adds a method to PluginASTAction which allows it to declare that the
action happens before, instead of, or after the main AST action, plus the
relevant changes to make the plugin action happen at that time automatically.

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

llvm-svn: 263546

show more ...

[Frontend] Make sure WrapperFrontendAction updates CurrentInput after calling BeginSourceFileAction.

I don't have a test case to add unfortunately.

llvm-svn: 260937

[Frontend] Make the memory management of FrontendAction pointers explicit by using unique_ptr.

llvm-svn: 260048

Roll-back r250822.

Summary: It breaks the build for the ASTMatchers

Subscribers: klimek, cfe-commits

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

llvm-svn: 250827

Apply modernize-use-default to clang.

Summary: Replace empty bodies of default constructors and destructors with '= default'.

Reviewers: bkramer, klimek

Subscribers: klimek, alexfh, cfe-commits

D

Apply modernize-use-default to clang.

Summary: Replace empty bodies of default constructors and destructors with '= default'.

Reviewers: bkramer, klimek

Subscribers: klimek, alexfh, cfe-commits

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

llvm-svn: 250822

show more ...

Fix crash on invalid if we can't find a suitable PCH file in a specified
directory, and our frontend action cares whether the frontend setup actually
succeeded.

llvm-svn: 246881

Add a -gmodules option to the driver and a -dwarf-ext-refs to cc1
to enable the use of external type references in the debug info
(a.k.a. module debugging).

The driver expands -gmodules to "-g -fmod

Add a -gmodules option to the driver and a -dwarf-ext-refs to cc1
to enable the use of external type references in the debug info
(a.k.a. module debugging).

The driver expands -gmodules to "-g -fmodule-format=obj -dwarf-ext-refs"
and passes that to cc1. All this does at the moment is set a flag
codegenopts.

http://reviews.llvm.org/D11958

llvm-svn: 246192

show more ...

[modules] Stop dropping 'module.timestamp' files into the current directory
when building with implicit modules disabled.

llvm-svn: 245136

Rename the non-coding style conformant functions in namespace Builtins
to match the rest of their brethren and reformat the bits that need it.

llvm-svn: 244186

Make the clang module container format selectable from the command line.
- introduces a new cc1 option -fmodule-format=[raw,obj]
with 'raw' being the default
- supports arbitrary module container f

Make the clang module container format selectable from the command line.
- introduces a new cc1 option -fmodule-format=[raw,obj]
with 'raw' being the default
- supports arbitrary module container formats that libclang is agnostic to
- adds the format to the module hash to avoid collisions
- splits the old PCHContainerOperations into PCHContainerWriter and
a PCHContainerReader.

Thanks to Richard Smith for reviewing this patch!

llvm-svn: 242499

show more ...

Introduce a PCHContainerOperations interface (NFC).

A PCHContainerOperations abstract interface provides operations for
creating and unwrapping containers for serialized ASTs (precompiled
headers an

Introduce a PCHContainerOperations interface (NFC).

A PCHContainerOperations abstract interface provides operations for
creating and unwrapping containers for serialized ASTs (precompiled
headers and clang modules). The default implementation is
RawPCHContainerOperations, which uses a flat file for the output.

The main application for this interface will be an
ObjectFilePCHContainerOperations implementation that uses LLVM to
wrap the module in an ELF/Mach-O/COFF container to store debug info
alongside the AST.

rdar://problem/20091852

llvm-svn: 240225

show more ...

Reapply "Frontend: Stop leaking when not -disable-free"

This reverts commit r236422, effectively reapplying r236419. ASan
helped me diagnose the problem: the non-leaking logic would free the
ASTCon

Reapply "Frontend: Stop leaking when not -disable-free"

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.

llvm-svn: 236424

show more ...

Revert "Frontend: Stop leaking when not -disable-free"

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

http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/26124
http://b

Revert "Frontend: Stop leaking when not -disable-free"

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

--

llvm-svn: 236422

show more ...

Frontend: Stop leaking when not -disable-free

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

Frontend: Stop leaking when not -disable-free

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.

llvm-svn: 236419

show more ...