aboutsummaryrefslogtreecommitdiff
path: root/clang/unittests/libclang
AgeCommit message (Collapse)AuthorFilesLines
2025-04-30[clang] Shard out some small gtest binaries (#138021)Reid Kleckner2-3/+4
@nico mentioned that FormatTests and BasicTests are small binaries with few dependencies, so keeping them separate is nice. I broke them out as distinct test binaries, and they are still pretty small: $ find tools/clang/unittests/ -type f -name '*Tests' | xargs du -cksh | sort -nr 708M total 276M tools/clang/unittests/AllClangUnitTests 244M tools/clang/unittests/Interpreter/ClangReplInterpreterTests 167M tools/clang/unittests/Interpreter/ExceptionTests/ClangReplInterpreterExceptionTests 13M tools/clang/unittests/Format/FormatTests 6.9M tools/clang/unittests/Basic/BasicTests 1.1M tools/clang/unittests/libclang/CrashTests/libclangCrashTests I also broke out libclangCrashTests and re-enabled the failing test to resolve llvm#137855.
2025-04-29[clang] Disable libclang abort death test after merging unittestsReid Kleckner1-1/+2
Death tests are often sensitive to global process state, which is dirtier now that the scope of the test binary has increased significantly. I think the value of this single death test isn't high enough to roll back the gtest binary merging patch, so I'm disabling it. See issue #137855 for the investigation.
2025-04-23[libclang/C++] Fix clang_File_isEqual for in-memory files (#135773)Jannick Kremer1-0/+49
Add tests for `clang_File_isEqual` (on-disk and in-memory)
2025-04-02Reapply "[cmake] Refactor clang unittest cmake" (#134195)Reid Kleckner2-8/+2
This reapplies 5ffd9bdb50b57 (#133545) with fixes. The BUILD_SHARED_LIBS=ON build was fixed by adding missing LLVM dependencies to the InterpTests binary in unittests/AST/ByteCode/CMakeLists.txt .
2025-04-01Revert "[cmake] Refactor clang unittest cmake" (#134022)dpalermo2-2/+8
Reverts llvm/llvm-project#133545 This change is breaking several buildbots as well as developer's builds. Reverting to allow people to make progress.
2025-04-01[cmake] Refactor clang unittest cmake (#133545)Reid Kleckner2-8/+2
Pass all the dependencies into add_clang_unittest. This is consistent with how it is done for LLDB. I borrowed the same named argument list structure from add_lldb_unittest. This is a necessary step towards consolidating unit tests into fewer binaries, but seems like a good refactoring in its own right.
2024-04-24[libclang] Compute the right spelling location (#72400)Sebastian Poeplau1-0/+31
Locations inside macro expansions have different spelling/expansion locations. Apply a FIXME to make the libclang function clang_getSpellingLocation return the right spelling location, and adapt the testsuite driver code to use the file location rather than the spelling location to compute source ranges. Co-authored-by: Matthieu Eyraud <eyraud@adacore.com>
2023-12-13[clang] Use StringRef::{starts,ends}_with (NFC) (#75149)Kazu Hirata1-3/+3
This patch replaces uses of StringRef::{starts,ends}with with StringRef::{starts,ends}_with for consistency with std::{string,string_view}::{starts,ends}_with in C++20. I'm planning to deprecate and eventually remove StringRef::{starts,ends}with.
2023-08-11[libclang] Expose arguments of clang::annotatefridtjof1-0/+46
This enables easy consumption of arbitrary data added to this annotation in addition to the annotation category, which was already exposed. This is a re-application of the changes in 5aa06b18940c9b96cbf1c31da6aee3fbb92183ed which were reverted in 332a34c71e7675ab4e0ebd28b0d2c15302a81a51. Differential Revision: https://reviews.llvm.org/D151373
2023-08-10Revert "[libclang] Expose arguments of clang::annotate"Vitaly Buka1-44/+0
Introduced a memory leak. This reverts commit 5aa06b18940c9b96cbf1c31da6aee3fbb92183ed.
2023-08-10[libclang] Expose arguments of clang::annotatefridtjof1-0/+44
This enables easy consumption of arbitrary data added to this annotation in addition to the annotation category, which was already exposed. Differential Revision: https://reviews.llvm.org/D151373
2023-07-25[Clang] use unsigned integer constants in unit-test | fixes build error on ↵Kai Stierand1-2/+2
ppc64le-lld-multistage-test Fixes: /home/buildbots/ppc64le-lld-multistage-test/ppc64le-lld-multistage-test/llvm-project/third-party/unittest/googletest/include/gtest/gtest.h:1526:11: warning: comparison of integer expressions of different signedness: ‘const unsigned int’ and ‘const int’ [-Wsign-compare] /home/buildbots/ppc64le-lld-multistage-test/ppc64le-lld-multistage-test/llvm-project/third-party/unittest/googletest/include/gtest/gtest.h:1526:11: warning: comparison of integer expressions of different signedness: ‘const long unsigned int’ and ‘const int’ [-Wsign-compare] Reviewed By: cor3ntin Differential Revision: https://reviews.llvm.org/D156224
2023-07-25[Clang] Fix crash in CIndex, when visiting a static_assert without messageKai Stierand2-6/+84
After implementation of "[Clang] Implement P2741R3 - user-generated static_assert messages" (47ccfd7a89e2a9a747a7114db18db1376324799c) the c indexer crashes when handling a `static_assert` w/o any message. This is caused by using `dyn_cast` to get the literal string, which isn't working on `nullptr`. Reviewed By: cor3ntin Differential Revision: https://reviews.llvm.org/D156053
2023-06-09[libclang] Add CXBinaryOperatorKind and CXUnaryOperatorKindMineGame1591-0/+34
Adds 2 new functions to the C libclang api for retrieving operator kinds for binary and unary operators from cursors. Also adds 2 functions for retrieving the spelling of the new enums. Fixes https://github.com/llvm/llvm-project/issues/29138 Differential Revision: https://reviews.llvm.org/D150910
2023-03-15[libclang] Add index option to store preambles in memoryIgor Kushnir1-0/+25
This commit allows libclang API users to opt into storing PCH in memory instead of temporary files. The option can be set only during CXIndex construction to avoid multithreading issues and confusion or bugs if some preambles are stored in temporary files and others - in memory. The added API works as expected in KDevelop: https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/283 Differential Revision: https://reviews.llvm.org/D145974
2023-03-07Fix build failures with libclang unittest; NFCAaron Ballman1-1/+2
This addresses the issue found by: https://lab.llvm.org/buildbot/#/builders/57/builds/25217 https://lab.llvm.org/buildbot/#/builders/36/builds/31018
2023-03-07[libclang] Add API to override preamble storage pathIgor Kushnir2-6/+172
TempPCHFile::create() calls llvm::sys::fs::createTemporaryFile() to create a file named preamble-*.pch in a system temporary directory. This commit allows overriding the directory where these often many and large preamble-*.pch files are stored. The referenced bug report requests the ability to override the temporary directory path used by libclang. However, overriding the return value of llvm::sys::path::system_temp_directory() was rejected during code review as improper and because it would negatively affect multithreading performance. Finding all places where libclang uses the temporary directory is very difficult. Therefore this commit is limited to override libclang's single known use of the temporary directory. This commit allows to override the preamble storage path only during CXIndex construction to avoid multithreading issues and ensure that all preambles are stored in the same directory. For the same multithreading and consistency reasons, this commit deprecates clang_CXIndex_setGlobalOptions() and clang_CXIndex_setInvocationEmissionPathOption() in favor of specifying these options during CXIndex construction. Adding a new CXIndex constructor function each time a new initialization argument is needed leads to either a large number of function parameters unneeded by most libclang users or to an exponential number of overloads that support different usage requirements. Therefore this commit introduces a new extensible struct CXIndexOptions and a general function clang_createIndexWithOptions(). A libclang user passes a desired preamble storage path to clang_createIndexWithOptions(), which stores it in CIndexer::PreambleStoragePath. Whenever clang_parseTranslationUnit_Impl() is called, it passes CIndexer::PreambleStoragePath to ASTUnit::LoadFromCommandLine(), which stores this argument in ASTUnit::PreambleStoragePath. Whenever ASTUnit::getMainBufferWithPrecompiledPreamble() is called, it passes ASTUnit::PreambleStoragePath to PrecompiledPreamble::Build(). PrecompiledPreamble::Build() forwards the corresponding StoragePath argument to TempPCHFile::create(). If StoragePath is not empty, TempPCHFile::create() stores the preamble-*.pch file in the directory at the specified path rather than in the system temporary directory. The analysis below proves that this passing around of the PreambleStoragePath string is sufficient to guarantee that the libclang user override is used in TempPCHFile::create(). The analysis ignores API uses in test code. TempPCHFile::create() is called only in PrecompiledPreamble::Build(). PrecompiledPreamble::Build() is called only in two places: one in clangd, which is not used by libclang, and one in ASTUnit::getMainBufferWithPrecompiledPreamble(). ASTUnit::getMainBufferWithPrecompiledPreamble() is called in 3 places: ASTUnit::LoadFromCompilerInvocation() [analyzed below]. ASTUnit::Reparse(), which in turn is called only from clang_reparseTranslationUnit_Impl(), which in turn is called only from clang_reparseTranslationUnit(). clang_reparseTranslationUnit() is never called in LLVM code, but is part of public libclang API. This function's documentation requires its translation unit argument to have been built with clang_createTranslationUnitFromSourceFile(). clang_createTranslationUnitFromSourceFile() delegates its work to clang_parseTranslationUnit(), which delegates to clang_parseTranslationUnit2(), which delegates to clang_parseTranslationUnit2FullArgv(), which delegates to clang_parseTranslationUnit_Impl(), which passes CIndexer::PreambleStoragePath to the ASTUnit it creates. ASTUnit::CodeComplete() passes AllowRebuild = false to ASTUnit::getMainBufferWithPrecompiledPreamble(), which makes it return nullptr before calling PrecompiledPreamble::Build(). Both ASTUnit::LoadFromCompilerInvocation() overloads (one of which delegates its work to another) call ASTUnit::getMainBufferWithPrecompiledPreamble() only if their argument PrecompilePreambleAfterNParses > 0. LoadFromCompilerInvocation() is called in: ASTBuilderAction::runInvocation() keeps the default parameter value of PrecompilePreambleAfterNParses = 0, meaning that the preamble file is never created from here. ASTUnit::LoadFromCommandLine(). ASTUnit::LoadFromCommandLine() is called in two places: CrossTranslationUnitContext::ASTLoader::loadFromSource() keeps the default parameter value of PrecompilePreambleAfterNParses = 0, meaning that the preamble file is never created from here. clang_parseTranslationUnit_Impl(), which passes CIndexer::PreambleStoragePath to the ASTUnit it creates. Therefore, the overridden preamble storage path is always used in TempPCHFile::create(). TempPCHFile::create() uses PreambleStoragePath in the same way as LibclangInvocationReporter() uses InvocationEmissionPath. The existing documentation for clang_CXIndex_setInvocationEmissionPathOption() does not specify ownership, encoding, separator or relative vs absolute path requirements. So the documentation for CXIndexOptions::PreambleStoragePath doesn't either. The assumptions are: no ownership transfer; UTF-8 encoding; native separators. Both relative and absolute paths are supported. The added API works as expected in KDevelop: https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/283 Fixes: https://github.com/llvm/llvm-project/issues/51847 Differential Revision: https://reviews.llvm.org/D143418
2023-03-01LibclangTest: remove libclang-test-* tmp dir reliablyIgor Kushnir2-6/+21
Temporary directories created by two LibclangReparseTest tests - ReparseWithModule and clang_parseTranslationUnit2FullArgv - remained in the system temporary directory after running libclangTests, because not all files and subdirectories created in TestDir were added to set LibclangParseTest::Files. Differential Revision: https://reviews.llvm.org/D143415
2023-01-02[clang] Use std::optional instead of llvm::Optional (NFC)Kazu Hirata1-1/+2
This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-11-26[clang] Use std::size (NFC)Kazu Hirata1-3/+3
std::size, introduced in C++17, allows us to directly obtain the number of elements of an array.
2022-10-11[libclang] CIndex: Visit UsingTypeLoc as TypeRefKai Stierand2-23/+44
Reviewed By: sammccall Differential Revision: https://reviews.llvm.org/D135555
2022-09-02Expose QualType::getNonReferenceType in libclangLuca Di Sera1-0/+40
The method is now wrapped by clang_getNonReferenceType. A declaration for clang_getNonReferenceType was added to clang-c/Index.h to expose it to user of the library. An implementation for clang_getNonReferenceType was introduced in CXType.cpp, wrapping the equivalent method of the underlying QualType of a CXType. An export symbol for the new function was added to libclang.map under the LLVM_16 version entry. A test was added to LibclangTest.cpp that tests the removal of ref-qualifiers for some CXTypes. The release-notes for the clang project was updated to include a notification of the new addition under the "libclang" section. Differential Revision: https://reviews.llvm.org/D133195
2022-08-29Expose QualType::getUnqualifiedType in libclangLuca Di Sera1-0/+48
The method is now wrapped by clang_getUnqualifiedType. A declaration for clang_getUnqualifiedType was added to clang-c/Index.h to expose it to user of the library. An implementation for clang_getUnqualifiedType was introduced in CXType.cpp that wraps the equivalent method of the underlying QualType of a CXType. An export symbol was added to libclang.map under the new version entry LLVM_16. A test was added to LibclangTest.cpp that tests the removal of qualifiers for some CXTypes. Differential Revision: https://reviews.llvm.org/D132749
2020-09-04[libclang] Add CXRewriter to libclang APIJan Korous1-0/+88
Differential Revision: https://reviews.llvm.org/D86992
2020-09-04[libclang] Expose couple more AST details via cursorsJan Korous1-0/+106
Differential Revision: https://reviews.llvm.org/D86991
2020-02-13Revert "Revert "Reland "[Support] make report_fatal_error `abort` instead of ↵Yuanfang Chen1-3/+3
`exit`""" This reverts commit 80a34ae31125aa46dcad47162ba45b152aed968d with fixes. Previously, since bots turning on EXPENSIVE_CHECKS are essentially turning on MachineVerifierPass by default on X86 and the fact that inline-asm-avx-v-constraint-32bit.ll and inline-asm-avx512vl-v-constraint-32bit.ll are not expected to generate functioning machine code, this would go down to `report_fatal_error` in MachineVerifierPass. Here passing `-verify-machineinstrs=0` to make the intent explicit.
2020-02-13Revert "Revert "Revert "Reland "[Support] make report_fatal_error `abort` ↵Yuanfang Chen1-3/+3
instead of `exit`"""" This reverts commit bb51d243308dbcc9a8c73180ae7b9e47b98e68fb.
2020-02-13Revert "Revert "Reland "[Support] make report_fatal_error `abort` instead of ↵Yuanfang Chen1-3/+3
`exit`""" This reverts commit 80a34ae31125aa46dcad47162ba45b152aed968d with fixes. On bots llvm-clang-x86_64-expensive-checks-ubuntu and llvm-clang-x86_64-expensive-checks-debian only, llc returns 0 for these two tests unexpectedly. I tweaked the RUN line a little bit in the hope that LIT is the culprit since this change is not in the codepath these tests are testing. llvm\test\CodeGen\X86\inline-asm-avx-v-constraint-32bit.ll llvm\test\CodeGen\X86\inline-asm-avx512vl-v-constraint-32bit.ll
2020-02-11Revert "Reland "[Support] make report_fatal_error `abort` instead of `exit`""Yuanfang Chen1-3/+3
This reverts commit rGcd5b308b828e, rGcd5b308b828e, rG8cedf0e2994c. There are issues to be investigated for polly bots and bots turning on EXPENSIVE_CHECKS.
2020-02-11Reland "[Support] make report_fatal_error `abort` instead of `exit`"Yuanfang Chen1-3/+3
Summary: Reland D67847 after D73742 is committed. Replace `sys::Process::Exit(1)` with `abort` in `report_fatal_error`. After this patch, for tools turning on `CrashRecoveryContext`, crash handler installed by `CrashRecoveryContext` is called unless they installed a non-returning handler using `llvm::install_fatal_error_handler` like `cc1_main` currently does. Reviewers: rnk, MaskRay, aganea, hans, espindola, jhenderson Subscribers: jholewinski, qcolombet, dschuff, jyknight, emaste, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, hiraditya, aheejin, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, jrtc27, zzheng, edward-jones, atanasyan, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, rupprecht, jocewei, jsji, Jim, dmgreen, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, kerbowa, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D74456
2020-01-28Make llvm::StringRef to std::string conversions explicit.Benjamin Kramer1-3/+3
This is how it should've been and brings it more in line with std::string_view. There should be no functional change here. This is mostly mechanical from a custom clang-tidy check, with a lot of manual fixups. It uncovers a lot of minor inefficiencies. This doesn't actually modify StringRef yet, I'll do that in a follow-up.
2020-01-15Revert "[Support] make report_fatal_error `abort` instead of `exit`"Yuanfang Chen1-3/+3
This reverts commit 647c3f4e47de8a850ffcaa897db68702d8d2459a. Got bots failure from sanitizer-windows and maybe others.
2020-01-15[Support] make report_fatal_error `abort` instead of `exit`Yuanfang Chen1-3/+3
Summary: This patch could be treated as a rebase of D33960. It also fixes PR35547. A fix for `llvm/test/Other/close-stderr.ll` is proposed in D68164. Seems the consensus is that the test is passing by chance and I'm not sure how important it is for us. So it is removed like in D33960 for now. The rest of the test fixes are just adding `--crash` flag to `not` tool. ** The reason it fixes PR35547 is `exit` does cleanup including calling class destructor whereas `abort` does not do any cleanup. In multithreading environment such as ThinLTO or JIT, threads may share states which mostly are ManagedStatic<>. If faulting thread tearing down a class when another thread is using it, there are chances of memory corruption. This is bad 1. It will stop error reporting like pretty stack printer; 2. The memory corruption is distracting and nondeterministic in terms of error message, and corruption type (depending one the timing, it could be double free, heap free after use, etc.). Reviewers: rnk, chandlerc, zturner, sepavloff, MaskRay, espindola Reviewed By: rnk, MaskRay Subscribers: wuzish, jholewinski, qcolombet, dschuff, jyknight, emaste, sdardis, nemanjai, jvesely, nhaehnle, sbc100, arichardson, jgravelle-google, aheejin, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, jsji, lenary, s.egerton, pzheng, cfe-commits, MaskRay, filcab, davide, MatzeB, mehdi_amini, hiraditya, steven_wu, dexonsmith, rupprecht, seiya, llvm-commits Tags: #llvm, #clang Differential Revision: https://reviews.llvm.org/D67847
2019-09-12[libclang] Fix UninstallAbortingLLVMFatalErrorHandler testJan Korous1-2/+3
llvm-svn: 371794
2019-09-12[libclang] Expose abort()-ing LLVM fatal error handlerJan Korous3-0/+46
Differential Revision: https://reviews.llvm.org/D66775 llvm-svn: 371787
2019-09-03[libclang][test][NFC] Split off fixture from tests.Jan Korous2-71/+95
llvm-svn: 370825
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-4/+3
to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2019-01-08[libclang] Recommit r336590 with a fix for the memory leak in the testAlex Lorenz1-0/+42
The original commit had a memory leak in the test has a leak as it doesn't dispose of the evaluated cursor result. This also contains the follow-up NFC refactoring commit r336591. rdar://45893054 Original commit message: [libclang] evalute compound statement cursors before trying to evaluate the cursor like a declaration This change fixes a bug in libclang in which it tries to evaluate a statement cursor as a declaration cursor, because that statement still has a pointer to the declaration parent. rdar://38888477 Differential Revision: https://reviews.llvm.org/D49051 llvm-svn: 350666
2018-07-10Revert r336590 "[libclang] evalute compound statement cursors before trying ↵Evgeniy Stepanov1-41/+0
to evaluate" New memory leaks in LibclangParseTest_EvaluateChildExpression_Test::TestBody() llvm-svn: 336716
2018-07-09[libclang] evalute compound statement cursors before trying to evaluateAlex Lorenz1-0/+41
the cursor like a declaration This change fixes a bug in libclang in which it tries to evaluate a statement cursor as a declaration cursor, because that statement still has a pointer to the declaration parent. rdar://38888477 Differential Revision: https://reviews.llvm.org/D49051 llvm-svn: 336590
2018-05-15[clang] Update uses of DEBUG macro to LLVM_DEBUG.Nicola Zaghen1-5/+7
The DEBUG() macro is very generic so it might clash with other projects. The renaming was done as follows: - git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g' - git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM Explicitly avoided changing the strings in the clang-format tests. Differential Revision: https://reviews.llvm.org/D44975 llvm-svn: 332350
2018-04-21[libclang] Fix LibclangReparseTest.FileName when TMPDIR is set to a symlinkPetr Pavlu1-2/+3
Fix testing of clang_File_tryGetRealPathName() in LibclangReparseTest.FileName when executing in an environment which has TMPDIR set to a symbolic link that points to an actual directory. The test would fail because the name returned by clang_File_tryGetRealPathName() has the symlink resolved but the test compared it to the original filename of a temporary file. The patch addresses the problem by checking only that the value returned by clang_File_tryGetRealPathName() ends with "main.cpp". Additionally, the patch makes the previous assertion in the test that checks result of clang_getFileName() stricter. It newly verifies that the name returned by the function is exactly same as what was given to clang_parseTranslationUnit()/clang_getFile(). Differential Revision: https://reviews.llvm.org/D45807 llvm-svn: 330507
2018-04-16Defer adding keywords to the identifier table until after the language ↵Aaron Ballman1-0/+64
options have been loaded from the AST file. This fixes issues with "class" being reported as an identifier in "enum class" because the construct is not present when using default language options. Patch by Johann Klähn. llvm-svn: 330159
2018-04-07[libclang] Add clang_File_tryGetRealPathNameFangrui Song1-0/+15
Summary: clang_getFileName() may return a path relative to WorkingDir. On Arch Linux, during clang_indexTranslationUnit(), clang_getFileName() on CXIdxIncludedIncludedFileInfo::file may return "/../lib64/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../include/c++/7.3.0/string", for `#include <string>`. I presume WorkingDir is somehow changed to /usr/lib or /usr/include and clang_getFileName() returns a path relative to WorkingDir. clang_File_tryGetRealPathName() returns "/usr/include/c++/7.3.0/string" which is more useful for the indexer in this case. Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D42893 llvm-svn: 329515
2018-01-16[libclang] Add PrintingPolicy for pretty printing declarationsJonathan Coe1-0/+30
Summary: Introduce clang_getCursorPrettyPrinted() for pretty printing declarations. Expose also PrintingPolicy, so the user gets more fine-grained control of the entities being printed. The already existing clang_getCursorDisplayName() is pretty limited - for example, it does not handle return types, parameter names or default arguments for function declarations. Addressing these issues in clang_getCursorDisplayName() would mean to duplicate existing code (e.g. clang::DeclPrinter), so rather expose new API to access the existing functionality. Reviewed By: jbcoe Subscribers: cfe-commits Tags: #clang Patch by nik (Nikolai Kosjar) Differential Revision: https://reviews.llvm.org/D39903 llvm-svn: 322540
2018-01-15Fixed memory leak in unit test introduced in my previous commit r322503Cameron Desrochers1-0/+3
llvm-svn: 322513
2018-01-15[PCH] Serialize skipped preprocessor rangesCameron Desrochers1-0/+78
The skipped preprocessor ranges are now serialized in the AST PCH file. This fixes, for example, libclang's clang_getSkippedRanges() returning zero ranges after reparsing a translation unit. Differential Revision: https://reviews.llvm.org/D20124 llvm-svn: 322503
2017-12-11Revert 320391: Certain targets are failing, pulling back to diagnose.Erich Keane1-3/+1
llvm-svn: 320398
2017-12-11For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is availableErich Keane1-1/+3
As reported in llvm bugzilla 32377. Here’s a patch to add preinclude of stdc-predef.h. The gcc documentation says “On GNU/Linux, <stdc-predef.h> is pre-included.” See https://gcc.gnu.org/gcc-4.8/porting_to.html; The preinclude is inhibited with –ffreestanding. Basically I fixed the failing test cases by adding –ffreestanding which inhibits this behavior. I fixed all the failing tests, including some in extra/test, there's a separate patch for that which is linked here Note: this is a recommit after a test failure took down the original (r318669) Patch By: mibintc Differential Revision: https://reviews.llvm.org/D34158 llvm-svn: 320391
2017-12-05[CMake] Use PRIVATE in target_link_libraries for executablesShoaib Meenai1-0/+1
We currently use target_link_libraries without an explicit scope specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables. Dependencies added in this way apply to both the target and its dependencies, i.e. they become part of the executable's link interface and are transitive. Transitive dependencies generally don't make sense for executables, since you wouldn't normally be linking against an executable. This also causes issues for generating install export files when using LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM library dependencies, which are currently added as interface dependencies. If clang is in the distribution components but the LLVM libraries it depends on aren't (which is a perfectly legitimate use case if the LLVM libraries are being built static and there are therefore no run-time dependencies on them), CMake will complain about the LLVM libraries not being in export set when attempting to generate the install export file for clang. This is reasonable behavior on CMake's part, and the right thing is for LLVM's build system to explicitly use PRIVATE dependencies for executables. Unfortunately, CMake doesn't allow you to mix and match the keyword and non-keyword target_link_libraries signatures for a single target; i.e., if a single call to target_link_libraries for a particular target uses one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must also be updated to use those keywords. This means we must do this change in a single shot. I also fully expect to have missed some instances; I tested by enabling all the projects in the monorepo (except dragonegg), and configuring both with and without shared libraries, on both Darwin and Linux, but I'm planning to rely on the buildbots for other configurations (since it should be pretty easy to fix those). Even after this change, we still have a lot of target_link_libraries calls that don't specify a scope keyword, mostly for shared libraries. I'm thinking about addressing those in a follow-up, but that's a separate change IMO. Differential Revision: https://reviews.llvm.org/D40823 llvm-svn: 319840