The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang
To reduce churn, not touching namespaces spanning less than 10 lines.
llvm-svn: 240270
A couple of these arguments were passed by void* as a rather extreme
example of pimpling. Adjusting this to a more classic form of the idiom
(involving forward declarations) makes this more legible and allows
explicit passing of ownership via std::unique_ptr.
llvm-svn: 216785
And in the process, discover that FileManager::removeStatCache had a
double-delete when removing an element from the middle of the list (at
the beginning or the end of the list, there was no problem) and add a
unit test to exercise the code path (which successfully crashed when run
(with modifications to match the old API) without this patch applied)
llvm-svn: 215388
This paves the way to making OnDiskHashTable work with hashes that are
not 32 bits wide and to making OnDiskHashTable work very large hash
tables. The LLVM change to use these types is upcoming.
llvm-svn: 206640
Committed this by accident before it was done last time.
Original message:
Rather than rolling our own functions to read little endian data
from a buffer, we can use the support in llvm's Endian.h.
No functional change.
llvm-svn: 205062
Committed this by accident before it was done last time.
Original message:
Rather than rolling our own functions to write little endian data
to an ostream, we can use the support in llvm's EndianStream.h.
No functional change.
llvm-svn: 205061
Rather than rolling our own functions to read little endian data from
a buffer, we can use the support in llvm's Endian.h.
No functional change.
llvm-svn: 205045
Rather than rolling our own functions to write little endian data to
an ostream, we can use the support in llvm's EndianStream.h.
No functional change.
llvm-svn: 205044
Was r202442
There were two issues with the original patch that have now been fixed.
1. We were memset'ing over a FileEntry in a test case. After adding a
std::string to FileEntry, this still happened to not break for me.
2. I didn't pass the FileManager into the new compiler instance in
compileModule. This was hidden in some cases by the fact I didn't
clear the module cache in the test.
Also, I changed the copy constructor for FileEntry, which was memcpy'ing
in a (now) unsafe way.
llvm-svn: 202539
Pass through the externally-visible names that we got from the VFS down
to FileManager, and test that this is the name showing up in __FILE__,
diagnostics, and debug information.
llvm-svn: 202442
Previously reverted in r201755 due to causing an assertion failure.
I've removed the offending assertion, and taught the CompilerInstance to
create a default virtual file system inside createFileManager. In the
future, we should be able to reach into the CompilerInvocation to
customize this behaviour without breaking clients that don't care.
llvm-svn: 201818
Replace the last incorrect uses and templatize the function to require a
compile-time constant string preventing further misuse.
The diagnostic formatter expects well-formed input and has undefined behaviour
with arbitrary input or crafted user strings in source files. Accepting user
input would also have caused unbounded generation of new diagnostic IDs which
can be problematic in long-running sessions or language bindings.
This completes the work to fix several incorrect callers that passed user
input or raw messages to the diagnostics engine where a constant format string
was expected.
llvm-svn: 200132
Before this patch, Lex() would recurse whenever the current lexer changed (e.g.
upon entry into a macro). This patch turns the recursion into a loop: the
various lex routines now don't return a token when the current lexer changes,
and at the top level Preprocessor::Lex() now loops until it finds a token.
Normally, the recursion wouldn't end up being very deep, but the recursion depth
can explode in edge cases like a bunch of consecutive macros which expand to
nothing (like in the testcase test/Preprocessor/macro_expand_empty.c in this
patch).
<rdar://problem/14569770>
llvm-svn: 190980
This unifies the unix and windows versions of FileManager::UniqueDirContainer
and FileManager::UniqueFileContainer by using UniqueID.
We cannot just replace "struct stat" with llvm::sys::fs::file_status, since we
want to be able to construct fake ones, and file_status has different members
on unix and windows.
What the patch does is:
* Record only the information that clang is actually using.
* Use llvm::sys::fs::status instead of stat and fstat.
* Use llvm::sys::fs::UniqueID
* Delete the old windows versions of UniqueDirContainer and
UniqueFileContainer since the "unix" one now works on windows too.
llvm-svn: 187619
a file or directory, allowing just a stat call if a file descriptor
is not needed.
Doing just 'stat' is faster than 'open/fstat/close'.
This has the effect of cutting down system time for validating the input files of a PCH.
llvm-svn: 169831
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
Previously we would cut off the source file buffer at the code-completion
point; this impeded code-completion inside C++ inline methods and,
recently, with buffering ObjC methods.
Have the code-completion inserted into the source buffer so that it can
be buffered along with a method body. When we actually hit the code-completion
point the cut-off lexing or parsing.
Fixes rdar://10056932&8319466
llvm-svn: 139086
The previous name was inaccurate as this token in fact appears at
the end of every preprocessing directive, not just macro definitions.
No functionality change, except for a diagnostic tweak.
llvm-svn: 126631
pointer that is passed down through the APIs, and make
FileSystemStatCache::get be the one that filters out
directory lookups that hit files. This also paves the
way to have stat queries be able to return opened files.
llvm-svn: 120060