I guess it would be working since Rafael's r187619.

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

For multi-stage builds we need to pass any overridden source directory variables. Without passing these the subsequent stages won't find the project sources.

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

I had hoped this would work from a single cache file, but turns out there is a bug I can't quite figure out relating to passing list arguments to recursive CMake invocations.

This change works around that.

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

Summary: This isn't a FileCheck directive; it does nothing.

Reviewers: jroelofs

Subscribers: cfe-commits, majnemer

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

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

This patch adds doxygen comments for all the intrinsincs in the header file f16cintrin.h. The doxygen comments are automatically generated based on Sony's intrinsics document.

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



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

Update documentation to reflect that libc++abi provides __cxa_thread_atexit (and has for quite a while). Also document that we have not yet implemented the new inheriting constructor rules.


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

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

that type from the global scope.

Patch by Sterling Augustine, derived (with permission) from code from Cling by
Vassil Vassilev and Philippe Canal.


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

what it's actually trying to do.


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

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

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





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

This is the third time it has crossed the 2^16 section limit. We've
already spent time optimizing this file to reduce template
instantiations, and it's not clear that there is anymore low hanging
fruit.

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

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

This builds on the support being added to LLVM to import and export
registries from DLLs.  This will allow us to pick up the registry
entries added in the DLL's copy of FrontendPluginRegistry.

This will allow us to use plugins on Windows using:
$ clang-cl -Xclang -load -Xclang plugin.dll \
           -Xclang -add-plugin -Xclang foo

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

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

It isn't much benefit and doesn't worth the complexity to try to handle them after the container is encountered.

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

[libclang] indexing: for a synthesized property reference have the parent be the ObjC implementation decl.

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

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

[ASTUnit] Change the parameter of ASTUnit::LoadFromCompilerInvocationAction to accept a more general FrontendAction.

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

[libclang] indexing: Have the semantic container of synthesized ObjC getter/setter methods be the implementation decl.

Matches the behavior of other ObjC methods.

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

While this won't help fix things like the bug that r260219 addressed, it
seems like good tidy up to have anyway.

(it might be nice if "makeArrayRef" always produced a MutableArrayRef &
let it decay to an ArrayRef when needed - then I'd use that for the
MutableArrayRefs in this patch)

If we had std::dynarray I'd use that instead of unique_ptr+size_t,
ideally (but then it'd have to be threaded down through the Preprocessor
all the way - no idea how painful that would be)

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

This reverts commit r260194.

It caused PR26549. There's probably a better way to do this also.

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

Use the VFTable components to determine whether or not we should emit
RTTI data instead of duplicating the VFTableBuilder's logic.

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

Registering the gnuNullExpr AST matcher as a dynamic matcher so that it is available from clang-query.

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

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

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

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

directive.

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

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

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

Clang did not expanded macros in the very first token of the pragmas
during preprocessed output

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

This is in response to silvas' post-commit suggestion.

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

This cache file can be used to generate a 3-stage clang build. You can configure using the following CMake command:

cmake -C <path to clang>/cmake/caches/3-stage.cmake -G Ninja <path to llvm>

You can then run "ninja stage3-clang" to build stage1, stage2 and stage3 clangs.

This is useful for finding non-determinism the compiler by verifying that stage2 and stage3 are identical.

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

Fixes PR26490

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

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

being called with the wrong size: convert CGFunctionInfo to use TrailingObjects
and ask TrailingObjects to provide a working 'operator delete' for us.


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

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

This patch adds doxygen comments for all the intrinsincs in the header file pmmintrin.h. The doxygen comments are automatically generated based on Sony's intrinsics document.

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



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

For an explicit specialization, we first build a FunctionDecl, and then
we call SubstDecl() on it to build a second FunctionDecl, which has the
first FunctionDecl as canonical decl.

The address of an explicit specialization of function template used to be the
canonical decl of the FunctionDecl.  This is different from all the other
DeduceTemplateArguments() calls in SemaOverload, and since the canonical decl
isn't visited by ParentMap while the redecl is, it also made ParentMap assert
when computing the parent of a address-of-explicit-specialization-fun-template.

To fix, remove the getCanonicalDecl() call.  No behavior difference for clang,
but it fixes an assert in ParentMap (which is e.g. used by libTooling).


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

because the information is now stored in TemplateDecl.

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