aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Frontend/InitHeaderSearch.cpp
AgeCommit message (Collapse)AuthorFilesLines
2022-01-11[clang] Move `ApplyHeaderSearchOptions` from Frontend to LexJan Svoboda1-687/+0
In D116750, the `clangFrontend` library was added as a dependency of `LexTests` in order to make `clang::ApplyHeaderSearchOptions()` available. This increased the number of TUs the test depends on. This patch moves the function into `clangLex` and removes dependency of `LexTests` on `clangFrontend`. Reviewed By: thakis Differential Revision: https://reviews.llvm.org/D117024
2021-12-26Remove redundant string initialization (NFC)Kazu Hirata1-1/+1
Identified with readability-redundant-string-init.
2021-10-12[clang][lex] Remark on search path usageJan Svoboda1-26/+57
For dependency scanning, it would be useful to collect header search paths (provided on command-line via `-I` and friends) that were actually used during preprocessing. This patch adds that feature to `HeaderSearch` along with a new remark that reports such paths as they get used. Previous version of this patch tried to use the existing `LookupFileCache` to report used paths via `HitIdx`. That doesn't work for `ComputeUserEntryUsage` (which is intended to be called *after* preprocessing), because it indexes used search paths by the file name. This means the values get overwritten when the code contains `#include_next`. Note that `HeaderSearch` doesn't use `HeaderSearchOptions::UserEntries` directly. Instead, `InitHeaderSearch` pre-processes them (adds platform-specific paths, removes duplicates, removes paths that don't exist) and creates `DirectoryLookup` instances. This means we need a mechanism for translating between those two. It's not possible to go from `DirectoryLookup` back to the original `HeaderSearch`, so `InitHeaderSearch` now tracks the relationships explicitly. Depends on D111557. Reviewed By: dexonsmith Differential Revision: https://reviews.llvm.org/D102923
2021-05-28[clang] NFC: Replace std::pair by a struct in InitHeaderSearchJan Svoboda1-20/+24
This patch replaces a `std::pair` by a proper struct in `InitHeaderSearch`. This will be useful in a follow-up: D102923. Reviewed By: dexonsmith Differential Revision: https://reviews.llvm.org/D102924
2020-08-23[clang][Driver] Implement AddClangSystemIncludeArgs and HasNativeLLVMSupport ↵Brad Smith1-0/+2
for the OpenBSD clang driver. If not overridden, AddClangSystemIncludeArgs's implementation is empty, so by default, no system include args are added to the Clang driver. This means that invoking Clang without the frontend must include a manual -I/usr/include flag, which is inconsistent behavior. Therefore, override and implement this method to match. Some boilerplate is also borrowed for handling of the other driver flags. While we are here, also override and enable HasNativeLLVMSupport. Patch by: 3405691582 (dana koch) Differential Revision: https://reviews.llvm.org/D86412
2020-07-07[Clang] Handle AIX Include management in the driverShuhong Liu1-0/+2
Summary: Modify the AIX clang toolchain to include AIX dependencies in the search path Reviewers: daltenty, stevewan, hubert.reinterpretcast Reviewed By: daltenty, stevewan, hubert.reinterpretcast Subscribers: ormris, hubert.reinterpretcast, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D82677
2020-02-27[WebAssembly] Mangle the argc/argv `main` as `__wasm_argc_argv`.Dan Gohman1-2/+1
WebAssembly enforces a rule that caller and callee signatures must match. This means that the traditional technique of passing `main` `argc` and `argv` even when it doesn't need them doesn't work. Currently the backend renames `main` to `__original_main`, however this doesn't interact well with LTO'ing libc, and the name isn't intuitive. This patch allows us to transition to `__main_argc_argv` instead. This implements the proposal in https://github.com/WebAssembly/tool-conventions/pull/134 with a flag to disable it when targeting Emscripten, though this is expected to be temporary, as discussed in the proposal comments. Differential Revision: https://reviews.llvm.org/D70700
2020-01-29Fix more implicit conversions. Getting closer to having clang working with ↵Benjamin Kramer1-1/+1
gcc 5 again
2020-01-28Make llvm::StringRef to std::string conversions explicit.Benjamin Kramer1-5/+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.
2019-09-13Reland r371785: Add -Wpoison-system-directories warningManoj Gupta1-0/+7
When using clang as a cross-compiler, we should not use system headers to do the compilation. This CL adds support of a new warning flag -Wpoison-system-directories which emits warnings if --sysroot is set and headers from common host system location are used. By default the warning is disabled. The intention of the warning is to catch bad includes which are usually generated by third party build system not targeting cross-compilation. Such cases happen in Chrome OS when someone imports a new package or upgrade one to a newer version from upstream. This is reland of r371785 with a fix to test file. Patch by: denik (Denis Nikitin) llvm-svn: 371878
2019-09-13Revert r371785.Manoj Gupta1-7/+0
r371785 is causing fails on clang-hexagon-elf buildbots. llvm-svn: 371799
2019-09-12Add -Wpoison-system-directories warningManoj Gupta1-0/+7
When using clang as a cross-compiler, we should not use system headers to do the compilation. This CL adds support of a new warning flag -Wpoison-system-directories which emits warnings if --sysroot is set and headers from common host system location are used. By default the warning is disabled. The intention of the warning is to catch bad includes which are usually generated by third party build system not targeting cross-compilation. Such cases happen in Chrome OS when someone imports a new package or upgrade one to a newer version from upstream. Patch by: denik (Denis Nikitin) llvm-svn: 371785
2019-08-31Introduce a DirectoryEntryRef that stores both a reference and anAlex Lorenz1-1/+1
accessed name to the directory entry This commit introduces a parallel API that returns a DirectoryEntryRef to the FileManager, similar to the parallel FileEntryRef API. All uses will have to be update in follow-up patches. The immediate use of the new API in this patch fixes the issue where a file manager was reused in clang-scan-deps, but reported an different file path whenever a framework lookup was done through a symlink. Differential Revision: https://reviews.llvm.org/D67026 llvm-svn: 370562
2019-08-01[clang] Adopt new FileManager error-returning APIsHarlan Haskins1-6/+6
Update the callers of FileManager::getFile and FileManager::getDirectory to handle the new llvm::ErrorOr-returning methods. Signed-off-by: Harlan Haskins <harlan@apple.com> llvm-svn: 367616
2019-06-13[WebAssembly] Modernize include path handlingSam Clegg1-0/+8
Move include path construction from InitHeaderSearch::AddDefaultIncludePaths in the Driver which appears to be the more modern/correct way of doing things. Differential Revision: https://reviews.llvm.org/D63030 llvm-svn: 363241
2019-05-21[clang][Darwin] Refactor header search path logic into the driverLouis Dionne1-51/+15
Summary: This commit moves the logic for determining system, resource and C++ header search paths from CC1 to the driver. This refactor has already been made for several platforms, but Darwin had been left behind. This refactor tries to implement the previous search path logic with perfect accuracy. In particular, the order of all include paths inside CC1 and all paths that were skipped because nonexistent are conserved after the refactor. This change was also tested against a code base of significant size and revealed no problems. Reviewers: jfb, arphaman Subscribers: nemanjai, javed.absar, kbarton, christof, jkorous, dexonsmith, jsji, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61963 llvm-svn: 361278
2019-02-23Remove OpenBSD case for old system libstdc++ header path as OpenBSDBrad Smith1-8/+0
has switched to libc++. llvm-svn: 354723
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
2018-12-05Move detection of libc++ include dirs to Driver on MacOSIlya Biryukov1-16/+0
Summary: The intention is to make the tools replaying compilations from 'compile_commands.json' (clang-tidy, clangd, etc.) find the same standard library as the original compiler specified in 'compile_commands.json'. Previously, the library detection logic was in the frontend (InitHeaderSearch.cpp) and relied on the value of resource dir as an approximation of the compiler install dir. The new logic uses the actual compiler install dir and is performed in the driver. This is consistent with the C++ standard library detection on other platforms and allows to override the resource dir in the tools using the compile_commands.json without altering the standard library detection mechanism. The tools have to override the resource dir to make sure they use a consistent version of the builtin headers. There is still logic in InitHeaderSearch that attemps to add the absolute includes for the the C++ standard library, so we keep passing the -stdlib=libc++ from the driver to the frontend via cc1 args to avoid breaking that. In the long run, we should move this logic to the driver too, but it could potentially break the library detection on other systems, so we don't tackle it in this patch to keep its scope manageable. This is a second attempt to fix the issue, first one was commited in r346652 and reverted in r346675. The original fix relied on an ad-hoc propagation (bypassing the cc1 flags) of the install dir from the driver to the frontend's HeaderSearchOptions. Unsurpisingly, the propagation was incomplete, it broke the libc++ detection in clang itself, which caused LLDB tests to break. The LLDB tests pass with new fix. Reviewers: JDevlieghere, arphaman, EricWF Reviewed By: arphaman Subscribers: mclow.lists, ldionne, dexonsmith, ioeric, christof, kadircet, cfe-commits Differential Revision: https://reviews.llvm.org/D54630 llvm-svn: 348365
2018-11-29Add Hurd target to Clang driver (2/2)Kristina Brooks1-0/+3
This adds Hurd toolchain support to Clang's driver in addition to handling translating the triple from Hurd-compatible form to the actual triple registered in LLVM. (Phabricator was stripping the empty files from the patch so I manually created them) Patch by sthibaul (Samuel Thibault) Differential Revision: https://reviews.llvm.org/D54379 llvm-svn: 347833
2018-11-12Revert "Make clang-based tools find libc++ on MacOS"Jonas Devlieghere1-3/+8
This breaks the LLDB bots. llvm-svn: 346675
2018-11-12Make clang-based tools find libc++ on MacOSIlya Biryukov1-8/+3
Summary: When they read compiler args from compile_commands.json. This change allows to run clang-based tools, like clang-tidy or clangd, built from head using the compile_commands.json file produced for XCode toolchains. On MacOS clang can find the C++ standard library relative to the compiler installation dir. The logic to do this was based on resource dir as an approximation of where the compiler is installed. This broke the tools that read 'compile_commands.json' and don't ship with the compiler, as they typically change resource dir. To workaround this, we now use compiler install dir detected by the driver to better mimic the behavior of the original compiler when replaying the compilations using other tools. Reviewers: sammccall, arphaman, EricWF Reviewed By: sammccall Subscribers: ioeric, christof, kadircet, cfe-commits Differential Revision: https://reviews.llvm.org/D54310 llvm-svn: 346652
2018-10-30NFC: Remove the ObjC1/ObjC2 distinction from clang (and related projects)Erik Pilkington1-4/+4
We haven't supported compiling ObjC1 for a long time (and never will again), so there isn't any reason to keep these separate. This patch replaces LangOpts::ObjC1 and LangOpts::ObjC2 with LangOpts::ObjC. Differential revision: https://reviews.llvm.org/D53547 llvm-svn: 345637
2018-06-28[frontend] Don't include the C++ stdlib for -x assembler-with-cppAlex Lorenz1-2/+2
The new C++ stdlib warning added in r335081 gets triggered when compiling an assembly file with -x assembler-with-cpp. This commit ensures that the C++ stdlib is not included when compiling assembly. In general, it's not really useful to include the C++ stdlib search path when compiling assembly source. rdar://41359632 Differential Revision: https://reviews.llvm.org/D48736 llvm-svn: 335940
2018-06-19Recommit r335063: [Darwin] Add a warning for missing include path for libstdc++Alex Lorenz1-35/+48
The recommit ensures that the tests that failed on bots don't trigger the warning. Xcode 10 removes support for libstdc++, but the users just get a confusing include not file warning when including an STL header (when building for iOS6 which uses libstdc++ by default for example). This patch adds a new warning that lets the user know that the libstdc++ include path was not found to ensure that the user is more aware of why the error occurs. rdar://40830462 Differential Revision: https://reviews.llvm.org/D48297 llvm-svn: 335081
2018-06-19Revert r335063 as it causes bot failuresAlex Lorenz1-48/+35
llvm-svn: 335073
2018-06-19[Darwin] Add a warning for missing include path for libstdc++Alex Lorenz1-35/+48
Xcode 10 removes support for libstdc++, but the users just get a confusing include not file warning when including an STL header (when building for iOS6 which uses libstdc++ by default for example). This patch adds a new warning that lets the user know that the libstdc++ include path was not found to ensure that the user is more aware of why the error occurs. rdar://40830462 Differential Revision: https://reviews.llvm.org/D48297 llvm-svn: 335063
2018-04-27s/LLVM_ON_WIN32/_WIN32/, clangNico Weber1-1/+1
LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in HandleLLVMOptions.cmake, which is where _WIN32 defined too. Just use the default macro instead of a reinvented one. See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev. No intended behavior change. llvm-svn: 331069
2018-03-02[Frontend] Avoid including default system header paths on FuchsiaPetr Hosek1-0/+2
These paths aren't used and don't make sense on Fuchsia. Differential Revision: https://reviews.llvm.org/D43992 llvm-svn: 326542
2018-01-23[Solaris] gcc toolchain handling revampFedor Sergeev1-0/+3
Summary: General idea is to utilize generic (mostly Generic_GCC) code and get rid of Solaris-specific handling as much as possible. In particular: - scanLibDirForGCCTripleSolaris was removed, relying on generic CollectLibDirsAndTriples - findBiarchMultilibs is now properly utilized to switch between m32 and m64 include & lib paths on Solaris - C system include handling copied from Linux (bar multilib hacks) Fixes PR24606. Reviewers: dlj, rafael, jyknight, theraven, tstellar Reviewed By: jyknight Subscribers: aaron.ballman, mgorny, krytarowski, ro, joerg, cfe-commits Differential Revision: https://reviews.llvm.org/D35755 llvm-svn: 323193
2017-10-02Revert "Add /System/Library/PrivateFrameworks as a header search path."Douglas Gregor1-1/+0
This reverts commit f7a95215a435aa8d5f64f43a8bb23ba077270755. llvm-svn: 314697
2017-09-14Add /System/Library/PrivateFrameworks as a header search path.Douglas Gregor1-0/+1
Addresses rdar://problem/34438708. llvm-svn: 313317
2017-07-21Remove Bitrig: Clang ChangesErich Keane1-1/+0
Bitrig code has been merged back to OpenBSD, thus the OS has been abandoned. Differential Revision: https://reviews.llvm.org/D35708 llvm-svn: 308797
2017-06-03Added LLVM_FALLTHROUGH to address warning: this statement may fall through. NFC.Galina Kistanova1-0/+2
llvm-svn: 304645
2016-12-02[Frontend] Fix an issue where a quoted search path is incorrectlyAlex Lorenz1-1/+1
removed as a duplicate header search path The commit r126167 started passing the First index into RemoveDuplicates, but forgot to update 0 to First in the loop that looks for the duplicate. This resulted in a bug where an -iquoted search path was incorrectly removed if you passed in the same path into -iquote and more than one time into -isystem. rdar://23991350 Differential Revision: https://reviews.llvm.org/D27298 llvm-svn: 288491
2016-10-01Use StringRef for MemoryBuffer identifier API (NFC)Mehdi Amini1-1/+1
llvm-svn: 283043
2016-07-18[NFC] Header cleanupMehdi Amini1-2/+1
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
2016-05-16[PS4] Change the names of some "environmental" things to what ourPaul Robinson1-1/+1
licensees actually see in the toolchain we deliver to them. This will reduce the set of local patches we have to maintain. The triple is not changing. (The term ORBIS is an internal code name for PS4.) llvm-svn: 269671
2016-05-11Update clang support on recent HaikuReid Kleckner1-32/+33
[ Copied from https://llvm.org/bugs/show_bug.cgi?id=26404 ] clang support on Haiku is lagging a bit, and missing on x86_64. This patch updates support for x86 and add support for x86_64. It should apply directly to trunk and it's harmless in the sense that it only affects Haiku. Reviewers: rnk, rsmith Patch by Jérôme Duval Differential Revision: http://reviews.llvm.org/D16797 llvm-svn: 269201
2015-12-30[ptr-traits] Add #includes of headers rather than forward declarationsChandler Carruth1-0/+1
for types which are used as pointees in PointerUnions, PointerIntPairs, and DenseMap pointer keys. This is part of a series of patches to allow LLVM to check for complete pointee types when computing its pointer traits. This is absolutely necessary to get correct (or reproducible) results for things like how many low bits are guaranteed to be zero. I think this is the last patch for getting Clang clean here!!! llvm-svn: 256615
2015-12-27Fix C++ support on recent DragonFly BSD releasesDimitry Andric1-4/+1
Summary: [ Copied from https://llvm.org/bugs/show_bug.cgi?id=25597 ] Clang support for DragonFly BSD is lagging a bit, resulting in poor support for c++. DragonFlyBSD is unique in that it has two base compilers. At the time of the last Clang update for DragonFly, these compilers were GCC 4.4 and GCC 4.7 (default). With DragonFly Release 4.2, GCC 4.4 was replaced with GCC 5.0, partially because the C++11 support of GCC 4.7 was incomplete. The DragonFly project will Release version 4.4 soon. This patch updates the Clang driver to use libstdc++ from GCC 5.2 The support for falling back to the alternate compiler was removed for two reasons: 1) The last release to use GCC 4.7 is DF 4.0 which has already reached EOL 2) GCC 4.7 libstdc++ is insufficient for many "ports" Therefore, I think it is reasonable that the development version of clang expects GCC 5.2 to be in place and not try to fall back to another compiler. The attached patch will do this. The Tools.cpp file was signficantly modified to fix the linking which had been changed somewhere along the line. The rest of the changes should be self-explanatory. Reviewers: joerg, rsmith, davide Subscribers: jrmarino, davide, cfe-commits Differential Revision: http://reviews.llvm.org/D15166 llvm-svn: 256467
2015-12-16[x86] Exclusion of incorrect include headers paths for MCU targetAndrey Bokhanko1-0/+2
Exclusion of /usr/include and /usr/local/include headers paths for MCU target. Differential Revision: http://reviews.llvm.org/D14954 llvm-svn: 255766
2015-10-14Bring back r250262: PS4 toolchainFilipe Cabecinhas1-0/+23
There was a minor problem with a test. Sorry for the noise yesterday. This patch adds missing pieces to clang, including the PS4 toolchain definition, added warnings, PS4 defaults, and Driver changes needed for our compiler. A patch by Filipe Cabecinhas, Pierre Gousseau and Katya Romanova! Differential Revision: http://reviews.llvm.org/D13482 llvm-svn: 250293
2015-10-14Revert-to-green r250262 (PS4 toolchain patch)Sean Silva1-23/+0
It is breaking llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast e.g. http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/1362 llvm-svn: 250273
2015-10-14I took care of the build problem in the commit 250252.Ekaterina Romanova1-0/+23
Resubmitting the patch. This patch adds missing pieces to clang, including the PS4 toolchain definition, added warnings, PS4 defaults, and Driver changes needed for our compiler. A patch by Filipe Cabecinhas, Pierre Gousseau and Katya Romanova! Differential Revision: http://reviews.llvm.org/D13482 llvm-svn: 250262
2015-10-14reverting my patch, cause build problemsEkaterina Romanova1-23/+0
llvm-svn: 250257
2015-10-13This patch adds missing pieces to clang, including the PS4 toolchainEkaterina Romanova1-0/+23
definition, added warnings, PS4 defaults, and Driver changes needed for our compiler. A patch by Filipe Cabecinhas, Pierre Gousseau and Katya Romanova! Differential Revision: http://reviews.llvm.org/D13482 llvm-svn: 250252
2015-10-01C++11 rangify for loops, NFC.Yaron Keren1-29/+21
llvm-svn: 249001
2015-09-25Revert "This patch adds missing pieces to clang, including the PS4 toolchain ↵Greg Bedwell1-23/+0
definition, added warnings, PS4 defaults, and Driver changes needed for our compiler." This reverts commit r248546 to get our bot green again while we discuss the best way forward. llvm-svn: 248578
2015-09-24This patch adds missing pieces to clang, including the PS4 toolchainEkaterina Romanova1-0/+23
definition, added warnings, PS4 defaults, and Driver changes needed for our compiler. A patch by Filipe Cabecinhas, Pierre Gousseau and Katya Romanova! Differential Revision: http://reviews.llvm.org/D11279 llvm-svn: 248546
generated by cgit v1.1 at 2025-10-13 00:19:25 +0000