This function doesn't seem to be used in-tree outside tests.
However clangd wants to use it soon, and having the CDB be self-contained seems
reasonable.
Differential Revision: https://reviews.llvm.org/D92646
Merge the key + sequence/value checks with the key handling code.
Reduces the number of key string comparisons and avoids a number of clang static analyzer null dereference warnings.
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.
Summary:
This is a follow-up to D70769 and D70222, which allows propagation of
current directory down to ExpandResponseFiles for handling of relative paths.
Previously clients had to mutate FS to achieve that, which is not thread-safe
and can even be thread-hostile in the case of real file system.
Reviewers: sammccall
Subscribers: hiraditya, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D70857
Summary:
It's common to use compiler wrappers by setting CC="gomacc clang++".
This results in both args appearing in compile_commands.json, and clang's driver
can't handle this.
This patch attempts to recognize this pattern (by looking for well-known
wrappers) and dropping argv0 in this case.
It conservatively ignores other cases for now:
- wrappers with unknown names
- wrappers that accept -flags
- wrappers where the compiler to use is implied (usually cc or gcc)
This is done at the JSONCompilationDatabase level rather than somewhere more
fundamental, as (hopefully) this isn't a general conceptual problem, but a messy
aspect of the nature of the ecosystem around compile_commands.json.
i.e. compilation databases more tightly tied to the build system should not have
this problem.
Reviewers: phosek, klimek
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64297
llvm-svn: 365887
Summary:
Wraps JSON compilation database with a target and mode adding database
wrapper. So that driver can correctly figure out which toolchain to use.
Note that clients that wants to make use of this target discovery mechanism
needs to link in TargetsInfos and initialize them at startup.
Reviewers: ilya-biryukov
Subscribers: mgorny, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D63755
llvm-svn: 364386
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
Summary:
See the existing InterpolatingCompilationDatabase for details on how this works.
We've been using this in clangd for a while, the heuristics seem to work well.
Reviewers: bkramer
Subscribers: ilya-biryukov, ioeric, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D51729
llvm-svn: 342228
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
In bigger projects like an Operating System, the same source code is
often compiled in slightly different ways. This could be the difference
between PIC and non-PIC code for static vs dynamic libraries, it could
also be the difference between size optimised versions of tools for
ramdisk images. At the moment, the compilation database has no way to
distinguish such cases. As first step, add a field in the JSON format
for it and process it accordingly.
Differential Revision: https://reviews.llvm.org/D27138
llvm-svn: 288436
This patch introduced the ability to decide at runtime whether to parse
JSON compilation database command lines using Gnu syntax or Windows
syntax. However, there were many existing unit tests written that
hardcoded Gnu-specific paths. These tests were now failing because
the auto-detection logic was choosing to parse them using Windows
rules.
This resubmission of the patch fixes this by introducing an enum
which defines the syntax mode, which defaults to auto-detect, but
for which the unit tests force Gnu style parsing.
Reviewed By: alexfh
Differential Revision: https://reviews.llvm.org/D23628
llvm-svn: 279120
This reverts commit 27a874790fc79f6391ad3703d7c790f51ac6ae1f.
After the introduction of windows command line parsing, some unit tests
began failing that expect to test gnu style command line quirks. The
fix is mechanical but time consuming, so revert this for now.
llvm-svn: 278976
When a compilation database is used on Windows, the command lines cannot
be parsed using the standard GNU style syntax. LLVM provides functions for
parsing Windows style command lines, so use them where appropriate.
After this patch, clang-tidy runs correctly on Windows.
Reviewed by: alexfh
Differential Revision: https://reviews.llvm.org/D23455
llvm-svn: 278964
This is useful for debugging of issues and reduction of test cases.
For example, an issue may show up due to the order that some commands were processed.
It is convenient to be able to remove commands from the file and still preserve the order
that they are returned, instead of getting a completely different order when removing a few commands.
llvm-svn: 248292
Currently, arguments are passed via the string attribute 'command',
assuming a shell-escaped / quoted command line to extract the original
arguments. This works well enough on Unix systems, but turns out to be
problematic for Windows tools to generate.
This CL adds a new attribute 'arguments', an array of strings, which
specifies the exact command line arguments. If 'arguments' is available
in the compilation database, it is preferred to 'commands'.
Currently there is no plan to retire 'commands': there are enough
different use cases where users want to create their own mechanism for
creating compilation databases, that it doesn't make sense to force them
all to implement shell command line parsing.
Patch by Daniel Dilts.
llvm-svn: 245036
If the type isn't trivially moveable emplace can skip a potentially
expensive move. It also saves a couple of characters.
Call sites were found with the ASTMatcher + some semi-automated cleanup.
memberCallExpr(
argumentCountIs(1), callee(methodDecl(hasName("push_back"))),
on(hasType(recordDecl(has(namedDecl(hasName("emplace_back")))))),
hasArgument(0, bindTemporaryExpr(
hasType(recordDecl(hasNonTrivialDestructor())),
has(constructExpr()))),
unless(isInTemplateInstantiation()))
No functional change intended.
llvm-svn: 238601
Now that SmallString is a first-class citizen, most SmallString::str()
calls are not required. This patch removes a whole bunch of them, yet
there are lots more.
There are two use cases where str() is really needed:
1) To use one of StringRef member functions which is not available in
SmallString.
2) To convert to std::string, as StringRef implicitly converts while
SmallString do not. We may wish to change this, but it may introduce
ambiguity.
llvm-svn: 232622
Diving into the memory leaks fixed by r213851 there was one case of a
memory leak of a CompilationDatabase due to not properly taking
ownership of the result of "CompilationDatabase::autoDetectFromSource".
Given that both implementations and callers have been using unique_ptr
to own CompilationDatabase objects - make this explicit in the API to
reduce the risk of further leaks.
llvm-svn: 215215
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
Sam McCall