summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver/Job.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [Clang] Limit -fintegrated-cc1 to only one TUAlexandre Ganea2020-02-131-2/+17
| | | | | | | | | | As discussed in https://reviews.llvm.org/D74447, this patch disables integrated-cc1 behavior if there's more than one job to be executed. This is meant to limit memory bloating, given that currently jobs don't clean up after execution (-disable-free is always active in cc1 mode). I see this behavior as temporary until release 10.0 ships (to ease merging of this patch), then we'll reevaluate the situation, see if D74447 makes more sense on the long term. Differential Revision: https://reviews.llvm.org/D74490 (cherry picked from commit 20f1abe306d030e99f56185a3aa077ffadf59b8a)
* [PATCH] Reland [Clang] Un-break scan-build after integrated-cc1 changeAlexandre Ganea2020-01-221-1/+1
| | | | | | | | | | | | The issue was reported by @xazax.hun here: https://reviews.llvm.org/D69825#1827826 "This patch (D69825) breaks scan-build-py which parses the output of "-###" to get -cc1 command. There might be other tools with the same problems. Could we either remove (in-process) from CC1Command::Print or add a line break? Having the last line as a valid invocation is valuable and there might be tools relying on that." Differential Revision: https://reviews.llvm.org/D72982 (cherry picked from commit 133a7e631cee97965e310f0d110739217427fd3d)
* [Clang][Driver] Re-use the calling process instead of creating a new process ↵Alexandre Ganea2020-01-131-33/+75
| | | | | | | | | | | | | | | for the cc1 invocation With this patch, the clang tool will now call the -cc1 invocation directly inside the same process. Previously, the -cc1 invocation was creating, and waiting for, a new process. This patch therefore reduces the number of created processes during a build, thus it reduces build times on platforms where process creation can be costly (Windows) and/or impacted by a antivirus. It also makes debugging a bit easier, as there's no need to attach to the secondary -cc1 process anymore, breakpoints will be hit inside the same process. Crashes or signaling inside the -cc1 invocation will have the same side-effect as before, and will be reported through the same means. This behavior can be controlled at compile-time through the CLANG_SPAWN_CC1 cmake flag, which defaults to OFF. Setting it to ON will revert to the previous behavior, where any -cc1 invocation will create/fork a secondary process. At run-time, it is also possible to tweak the CLANG_SPAWN_CC1 environment variable. Setting it and will override the compile-time setting. A value of 0 calls -cc1 inside the calling process; a value of 1 will create a secondary process, as before. Differential Revision: https://reviews.llvm.org/D69825
* Fix unquoted spaces in args in clang --verbose outputHans Wennborg2019-04-241-1/+1
| | | | | | | | | | | The behaviour of not quoting spaces appears to have been introduced by mistake in r190620. Patch by Brad Moody! Differential revision: https://reviews.llvm.org/D60997 llvm-svn: 359077
* Range-style std::find{,_if} -> llvm::find{,_if}. NFCFangrui Song2019-03-311-2/+2
| | | | llvm-svn: 357359
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-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
* Re-commit r344234 "clang-cl: Add /showFilenames option (PR31957)"Hans Wennborg2018-10-131-0/+6
| | | | | | | | The test was failing on e.g. PPC which can't target Windows. Fix by requiring X86 target in the test. Also, make sure the output goes to a temporary directory, since CWD may not be writable. llvm-svn: 344462
* Consistently make llvm::opt::ArgStringList usage explicit to try and appease ↵Simon Pilgrim2018-10-121-7/+6
| | | | | | MSVC 2015 buildbots. NFCI. llvm-svn: 344398
* Revert "clang-cl: Add /showFilenames option (PR31957)"Sean Fertile2018-10-111-6/+0
| | | | | | | This reverts https://reviews.llvm.org/rL344234 which is causing failures on several bots due to invalid llvm.linker.options. llvm-svn: 344276
* clang-cl: Add /showFilenames option (PR31957)Hans Wennborg2018-10-111-0/+6
| | | | | | | | | | | Add a /showFilenames option for users who want clang to echo the currently compiled filename. MSVC does this echoing by default, and it's useful for showing progress in build systems that doesn't otherwise provide any progress report, such as MSBuild. Differential Revision: https://reviews.llvm.org/D52773 llvm-svn: 344234
* Fix crash in clang.Zachary Turner2018-07-031-1/+3
| | | | | | | | | | This happened during a recent refactor. toStringRefArray() returns a vector<StringRef>, which was being implicitly converted to an ArrayRef<StringRef>, and then the vector was immediately being destroyed, so the ArrayRef<> was losing its backing storage. Fix this by making sure the vector gets permanent storage. llvm-svn: 336219
* Refactor ExecuteAndWait to take StringRefs.Zachary Turner2018-06-121-7/+7
| | | | | | | | | | | | | | | | | | | This simplifies some code which had StringRefs to begin with, and makes other code more complicated which had const char* to begin with. In the end, I think this makes for a more idiomatic and platform agnostic API. Not all platforms launch process with null terminated c-string arrays for the environment pointer and argv, but the api was designed that way because it allowed easy pass-through for posix-based platforms. There's a little additional overhead now since on posix based platforms we'll be takign StringRefs which were constructed from null terminated strings and then copying them to null terminate them again, but from a readability and usability standpoint of the API user, I think this API signature is strictly better. llvm-svn: 334518
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-091-2/+2
| | | | | | | | | | | | | | | | | | | This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
* [Driver] Fix some Clang-tidy modernize and Include What You Use warnings; ↵Eugene Zelenko2018-03-201-17/+22
| | | | | | other minor fixes (NFC). llvm-svn: 328044
* Revert 320391: Certain targets are failing, pulling back to diagnose.Erich Keane2017-12-111-1/+1
| | | | llvm-svn: 320398
* For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is availableErich Keane2017-12-111-1/+1
| | | | | | | | | | | | | | | | | | | | 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
* Revert r318669/318694Erich Keane2017-11-201-1/+1
| | | | | | Broke some libclang tests, so reverting for now. llvm-svn: 318698
* For Linux/gnu compatibility, preinclude <stdc-predef.h> if the file is availableErich Keane2017-11-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | 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 Patch By: mibintc Differential Revision: https://reviews.llvm.org/D34158 llvm-svn: 318669
* Revert r316193.Richard Smith2017-10-201-2/+2
| | | | | | | This patch breaks users using -fno-canonical-prefixes, for whom resolving symlinks is not acceptable. llvm-svn: 316195
* Try to shorten system header paths when using -MD depfilesPeter Wu2017-10-191-2/+2
| | | | | | | | | | | | | | | | | | | | | GCC tries to shorten system headers in depfiles using its real path (resolving components like ".." and following symlinks). Mimic this feature to ensure that the Ninja build tool detects the correct dependencies when a symlink changes directory levels, see https://github.com/ninja-build/ninja/issues/1330 An option to disable this feature is added in case "these changed header paths may conflict with some compilation environments", see https://gcc.gnu.org/ml/gcc-patches/2012-09/msg00287.html Note that the original feature request for GCC (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52974) also included paths preprocessed output (-E) and diagnostics. That is not implemented now since I am not sure if it breaks something else. Differential Revision: https://reviews.llvm.org/D37954 llvm-svn: 316193
* Attempt to fix MSVC build.Alexander Kornienko2017-09-131-3/+4
| | | | llvm-svn: 313162
* Update users of llvm::sys::ExecuteAndWait etc.Alexander Kornienko2017-09-131-5/+5
| | | | | | | | | | | | Summary: Clang part of https://reviews.llvm.org/D37563 Reviewers: bkramer Subscribers: vsk, cfe-commits Differential Revision: https://reviews.llvm.org/D37564 llvm-svn: 313156
* The -coverage-file flag was removed in r280306, and this piece was missed; NFC.Aaron Ballman2017-05-011-1/+1
| | | | llvm-svn: 301796
* [clang-cl] Fix cross-compilation with MSVC 2017.Zachary Turner2017-03-171-6/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | clang-cl works best when the user runs vcvarsall to set up an environment before running, but even this is not enough on VC 2017 when cross compiling (e.g. using an x64 toolchain to target x86, or vice versa). The reason is that although clang-cl itself will have a valid environment, it will shell out to other tools (such as link.exe) which may not. Generally we solve this through adding the appropriate linker flags, but this is not enough in VC 2017. The cross-linker and the regular linker both link against some common DLLs, but these DLLs live in the binary directory of the native linker. When setting up a cross-compilation environment through vcvarsall, it will add *both* directories to %PATH%, so that when cl shells out to any of the associated tools, those tools will be able to find all of the dependencies that it links against. If you don't do this, link.exe will fail to run because the loader won't be able to find all of the required DLLs that it links against. To solve this we teach the driver how to spawn a process with an explicitly specified environment. Then we modify the PATH before shelling out to subtools and run with the modified PATH. Patch by Hamza Sood Differential Revision: https://reviews.llvm.org/D30991 llvm-svn: 298098
* [CrashReproducer] Collect PCH included via -include-pchBruno Cardoso Lopes2016-12-121-3/+2
| | | | | | | | | | | | Collect the necessary input PCH files. Do not try to validate the AST before copying it out because if the crash is in this path, we won't be able to collect it. Instead only check if it's a file containg an AST. rdar://problem/27913709 llvm-svn: 289460
* [CrashReproducer] Provide a clean dir path for -fmodules-cache-pathBruno Cardoso Lopes2016-12-091-3/+6
| | | | | | | | | | | | The most common workflow with module reproducers involves deleting the module cache before running the script. This happens because leftovers from the crash are present in the cache and could trigger unrelated and confusing errors, misleading from the initial reproduction intent. Change this to point to a clean path but leave the leftovers untouched. rdar://problem/28655070 llvm-svn: 289176
* [CrashReproducer] Rewrite relative include pathsBruno Cardoso Lopes2016-12-091-24/+94
| | | | | | | | | | | | | | | | | When -fmodules is on, the reproducer invocation currently leave paths for include-like flags as is. If the path is relative, the reproducer doesn't know how to access that file during reproduction time because the VFS cannot reason about relative paths. Expand relative paths to absolute ones when creating the reproducer command line. This allows, for example, the reproducer to work for crashes while building clang with modules; this wasn't possible before because building clang requires using relative inc dir from within the build directory. rdar://problem/28655070 llvm-svn: 289174
* Fix Clang-tidy readability-redundant-string-cstr warningsMalcolm Parsons2016-11-021-3/+3
| | | | | | | | | | Reviewers: aaron.ballman, mehdi_amini, dblaikie Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D26206 llvm-svn: 285799
* Use StringRef in Command::printArg() instead of raw pointer (NFC)Mehdi Amini2016-10-081-3/+3
| | | | llvm-svn: 283645
* [NFC] Header cleanupMehdi Amini2016-07-181-2/+3
| | | | | | | | | | 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
* [CrashReproducer] Pass -I, -F and -resource-dir to the reproducer script ↵Bruno Cardoso Lopes2016-04-041-4/+4
| | | | | | | | | | when using modules/vfs The reproducer should use -I/-F/-resource-dir in the same way as the original command. The VFS already collects the right headers but without these flags the reproducer will fail to do the right thing. llvm-svn: 265343
* [CrashReproducer] Add -fmodule-cache-path to reproducer scriptBruno Cardoso Lopes2016-04-011-0/+13
| | | | | | | | The cc1 invocation in the reproducer script should contain a valid path in -fmodule-cache-path; for that reuse "<name>.cache/module" dir we already use to dump the vfs and modules. llvm-svn: 265162
* clang-cl: Implement initial limited support for precompiled headers.Nico Weber2016-03-011-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the gcc precompiled header model, one explicitly runs clang with `-x c++-header` on a .h file to produce a gch file, and then includes the header with `-include foo.h` and if a .gch file exists for that header it gets used. This is documented at http://clang.llvm.org/docs/UsersManual.html#precompiled-headers cl.exe's model is fairly different, and controlled by the two flags /Yc and /Yu. A pch file is generated as a side effect of a regular compilation when /Ycheader.h is passed. While the compilation is running, the compiler keeps track of #include lines in the main translation unit and writes everything up to an `#include "header.h"` line into a pch file. Conversely, /Yuheader.h tells the compiler to skip all code in the main TU up to and including `#include "header.h"` and instead load header.pch. (It's also possible to use /Yc and /Yu without an argument, in that case a `#pragma hrdstop` takes the role of controlling the point where pch ends and real code begins.) This patch implements limited support for this in that it requires the pch header to be passed as a /FI force include flag – with this restriction, it can be implemented almost completely in the driver with fairly small amounts of code. For /Yu, this is trivial, and for /Yc a separate pch action is added that runs before the actual compilation. After r261774, the first failing command makes a compilation stop – this means if the pch fails to build the main compilation won't run, which is what we want. However, in /fallback builds we need to run the main compilation even if the pch build fails so that the main compilation's fallback can run. To achieve this, add a ForceSuccessCommand that pretends that the pch build always succeeded in /fallback builds (the main compilation will then fail to open the pch and run the fallback cl.exe invocation). If /Yc /Yu are used in a setup that clang-cl doesn't implement yet, clang-cl will now emit a "not implemented yet; flag ignored" warning that can be disabled using -Wno-clang-cl-pch. Since clang-cl doesn't yet serialize some important things (most notably `pragma comment(lib, ...)`, this feature is disabled by default and only enabled by an internal driver flag. Once it's more stable, this internal flag will disappear. (The default stdafx.h setup passes stdafx.h as explicit argument to /Yc but not as /FI – instead every single TU has to `#include <stdafx.h>` as first thing it does. Implementing support for this should be possible with the approach in this patch with minimal frontend changes by passing a --stop-at / --start-at flag from the driver to the frontend. This is left for a follow-up. I don't think we ever want to support `#pragma hdrstop`, and supporting it with this approach isn't easy: This approach relies on the driver knowing the pch filename in advance, and `#pragma hdrstop(out.pch)` can set the output filename, so the driver can't know about it in advance.) clang-cl now also honors /Fp and puts pch files in the same spot that cl.exe would put them, but the pch file format is of course incompatible. This has ramifications on /fallback, so /Yc /Yu aren't passed through to cl.exe in /fallback builds. http://reviews.llvm.org/D17695 llvm-svn: 262420
* Driver: Strip -header-include-file and -diagnostic-log-file from crash repro ↵Justin Bogner2015-08-051-0/+1
| | | | | | | | | scripts These two arguments tend to refer to a local path that won't exist when we try to reproduce a bug. Strip them. llvm-svn: 244179
* Driver: Determine file names for crash reports more reliablyJustin Bogner2015-07-171-12/+15
| | | | | | | | Guessing which file name to replace based on the -main-file-name argument to -cc1 is flawed. Instead, keep track of which arguments are inputs to each command. llvm-svn: 242504
* [clang-cl] Use the Windows response file tokenizerReid Kleckner2015-07-151-1/+3
| | | | | | | | | | | | | | | | | | | | We were still using the Unix response file tokenizer for all driver modes. This was difficult to get right in the beginning because there is a circular dependency. The Driver class also can't officially determine its mode until it can see all possible --driver-mode= flags, and those flags could come from the response file. Now we use the Windows parsing algorithm if the program name looks like clang-cl, or if the --driver-mode=cl flag is present on the main command line. Fixes PR23709. Reviewers: hans Differential Revision: http://reviews.llvm.org/D11229 llvm-svn: 242346
* Driver: Include the driver arguments in crash reportsJustin Bogner2015-07-091-6/+6
| | | | | | | Similarly to r231989, the driver arguments can be quite helpful in diagnosing a crash. llvm-svn: 241786
* Driver: Remove the Job class. NFCJustin Bogner2015-07-021-6/+2
| | | | | | | | | | | We had a strange relationship here where we made a list of Jobs inherit from a single Job, but there weren't actually any places where this arbitrary nesting was used or needed. Simplify all of this by removing Job entirely and updating all of the users to either work with a JobList or a single Command. llvm-svn: 241310
* Driver: Don't use reserved names. NFCJustin Bogner2015-07-021-6/+4
| | | | llvm-svn: 241309
* Driver: Keep -isysroot flags in crash scripts if we're dumping a VFSJustin Bogner2015-03-121-4/+7
| | | | | | | | | | | | | For crashes with a VFS (ie, with modules), the -isysroot flag is often necessary to reproduce the crash. This is especially true if some modules need to be rebuilt, since without the sysroot they'll try to read headers that are outside of the VFS. I find it likely that we should keep some of the other -i flags in this case as well, but I haven't seen that come up in practice yet so it seems better to be conservative. llvm-svn: 231997
* Prefer SmallVector::append/insert over push_back loops. Clang edition.Benjamin Kramer2015-02-171-2/+1
| | | | | | Same functionality, but hoists the vector growth out of the loop. llvm-svn: 229508
* Driver: Quote the command in crash reproduction scripts.Justin Bogner2014-10-211-11/+0
| | | | | | | | This fixes crash report generation when filenames have spaces. It also removes an awkward workaround that quoted *some* arguments when generating crash reports. llvm-svn: 220307
* Driver: Move crash report command mangling into Command::PrintJustin Bogner2014-10-211-8/+29
| | | | | | | | | | This pushes the logic for generating a crash reproduction script entirely into Command::Print, instead of Command doing half of the work and then relying on textual substitution for the rest. This makes this logic much easier to read and will simplify fixing a couple of issues in this area. llvm-svn: 220305
* Driver: Use pointee_iterator rather than iterating over unique_ptrsJustin Bogner2014-10-031-2/+2
| | | | | | | | There's probably never a good reason to iterate over unique_ptrs. This lets us use range-for and say Job.foo instead of (*it)->foo in a few places. llvm-svn: 218938
* Teach Clang how to use response files when calling other toolsReid Kleckner2014-09-151-7/+117
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch by Rafael Auler! This patch addresses PR15171 and teaches Clang how to call other tools with response files, when the command line exceeds system limits. This is a problem for Windows systems, whose maximum command-line length is 32kb. I introduce the concept of "response file support" for each Tool object. A given Tool may have full support for response files (e.g. MSVC's link.exe) or only support file names inside response files, but no flags (e.g. Apple's ld64, as commented in PR15171), or no support at all (the default case). Therefore, if you implement a toolchain in the clang driver and you want clang to be able to use response files in your tools, you must override a method (getReponseFileSupport()) to tell so. I designed it to support different kinds of tools and internationalisation needs: - VS response files ( UTF-16 ) - GNU tools ( uses system's current code page, windows' legacy intl. support, with escaped backslashes. On unix, fallback to UTF-8 ) - Clang itself ( UTF-16 on windows, UTF-8 on unix ) - ld64 response files ( only a limited file list, UTF-8 on unix ) With this design, I was able to test input file names with spaces and international characters for Windows. When the linker input is large enough, it creates a response file with the correct encoding. On a Mac, to test ld64, I temporarily changed Clang's behavior to always use response files regardless of the command size limit (avoiding using huge command line inputs). I tested clang with the LLVM test suite (compiling benchmarks) and it did fine. Test Plan: A LIT test that tests proper response files support. This is tricky, since, for Unix systems, we need a 2MB response file, otherwise Clang will simply use regular arguments instead of a response file. To do this, my LIT test generate the file on the fly by cloning many -DTEST parameters until we have a 2MB file. I found out that processing 2MB of arguments is pretty slow, it takes 1 minute using my notebook in a debug build, or 10s in a Release build. Therefore, I also added "REQUIRES: long_tests", so it will only run when the user wants to run long tests. In the full discussion in http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130408/171463.html, Rafael Espindola discusses a proper way to test llvm::sys::argumentsFitWithinSystemLimits(), and, there, Chandler suggests to use 10 times the current system limit (20MB resp file), so we guarantee that the system will always use response file, even if a new linux comes up that can handle a few more bytes of arguments. However, by testing with a 20MB resp file, the test takes long 8 minutes just to perform a silly check to see if the driver will use a response file. I found it to be unreasonable. Thus, I discarded this approach and uses a 2MB response file, which should be enough. Reviewers: asl, rafael, silvas Reviewed By: silvas Subscribers: silvas, rnk, thakis, cfe-commits Differential Revision: http://reviews.llvm.org/D4897 llvm-svn: 217792
* unique_ptrify JobList::JobsDavid Blaikie2014-09-041-11/+4
| | | | llvm-svn: 217168
* Add back the leading space when printing commands with -###Reid Kleckner2014-08-071-0/+1
| | | | | | This was an unintentional behavior change from r214924. llvm-svn: 215044
* Make crash diagnostics on Windows the tiniest bit more usefulReid Kleckner2014-08-051-1/+2
| | | | | | | | | | | | | | This escapes any backslashes in the executable path and fixes an issue with a trailing quote when the main file name had to be quoted during printing. It's impossible to test this without putting backslashes or quotes into the executable path, so I didn't add automated tests. The crash diagnostics are still only useful if you're using bash on Windows, though. This should probably be writing a batch file instead. llvm-svn: 214924
* Driver: Skip the -ivfsoverlay argument in driver crash diagsJustin Bogner2014-06-221-1/+1
| | | | llvm-svn: 211474
* [C++11] Use 'nullptr'. Driver edition.Craig Topper2014-05-171-2/+2
| | | | llvm-svn: 209069
OpenPOWER on IntegriCloud