Introduce a type alias for the commonly used `std::pair<FileID,
unsigned>` to improve code readability, and make it easier for future
updates (64-bit source locations).
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.
This patch replaces use of the deprecated `FileEntry::getName()` with
`FileEntryRef::getName()`. This means the code now uses the path that
was used to register file entry in `SourceManager` instead of the
absolute path that happened to be used in the last call to
`FileManager::getFile()` some place else.
This caused some test failures due to the fact that some paths can be
relative and thus rely on the VFS CWD. The CWD can change for each TU,
so when we run `clang-tidy` on a compilation database and try to perform
all the replacements at the end, relative paths won't resolve the same.
This patch takes care to reinstate the correct CWD and make the path
reported by `FileEntryRef` absolute before passing it to
`llvm::writeToOutput()`.
This commit replaces some calls to the deprecated `FileEntry::getName()` with `FileEntryRef::getName()` by swapping current usages of `SourceManager::getFileEntryForID()` with `SourceManager::getFileEntryRefForID()`. This lowers the number of usages of the deprecated `FileEntry::getName()` from 95 to 50.
I currently have code that is crashing in the second std::advance call,
and it was not straightforward to identify the problem, as the first line
of the stacktrace is in RopePieceBTreeIterator::operator++:
```
*** SIGILL; stack trace: ***
PC: clang/include/clang/Rewrite/Core/RewriteRope.h:119 clang::RopePieceBTreeIterator::operator++()
../include/c++/v1/__iterator/advance.h:35 std::__u::__advance<>()
../include/c++/v1/__iterator/advance.h:65 std::__u::advance<>()
clang/lib/Rewrite/Rewriter.cpp:228 clang::Rewriter::getRewrittenText()
clang/include/clang/Rewrite/Core/Rewriter.h:106 clang::Rewriter::getRewrittenText()
```
Adding an assertion produces a friendlier error message for the caller.
Reviewed By: gribozavr2
Differential Revision: https://reviews.llvm.org/D117579
It turns out that `FileInfo` *always* has a ContentCache. Clarify that
in the code:
- Update the private version of `SourceManager::createFileID` to take a
`ContentCache&` instead of `ContentCache*`, and rename it to
`createFileIDImpl` for clarity.
- Change `FileInfo::getContentCache` to return a reference.
Differential Revision: https://reviews.llvm.org/D89554
I'd like to add these comments to warn others of problems I
encountered when trying to use `RemoveLineIfEmpty`. I originally
tried to fix the problem, but I realized I could implement the
functionality more easily and efficiently in my calling code where I
can make the simplifying assumption that there are no prior edits to
the line from which text is being removed. While I've lost the
motivation to write a fix, which doesn't look easy, I figure a warning
to others is better than silence.
I've added a unit test to demonstrate the problem. I don't know how
to mark it as an expected failure, so I just marked it disabled.
Reviewed By: jkorous
Differential Revision: https://reviews.llvm.org/D61466
llvm-svn: 369049
Some Rewrite functions are already overloaded to accept
CharSourceRange, and this extends others in the same manner. I'm
calling these in code that's not ready to upstream, but I figure they
might be useful to others in the meantime.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D61467
llvm-svn: 365258
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
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
isWhitespaceExceptNL. If that's wasn't bad enough, we have an identically
named function in Basic/CharInfo.h.
While at it, remove unnecessary includes, .str() calls and #ifdef.
llvm-svn: 243260
The rewrite facility's footprint is small so it's not worth going to these
lengths to support disabling at configure time, particularly since key compiler
features now depend on it.
Meanwhile the Objective-C rewriters have been moved under the
ENABLE_CLANG_ARCMT umbrella for now as they're comparatively heavy and still
potentially worth excluding from lightweight builds.
Tests are now passing with any combination of feature flags. The flags
historically haven't been tested by LLVM's build servers so caveat emptor.
llvm-svn: 213171
This is similar to how we divide up the StaticAnalyzer libraries to separate
core functionality to what is clearly associated with Frontend actions.
llvm-svn: 163050
first writing the changed files to a temporary location and then overwriting
the original files atomically.
Also adds a RewriterTestContext to aid unit testing rewrting logic in general.
llvm-svn: 157260
Language-design credit goes to a lot of people, but I particularly want
to single out Blaine Garst and Patrick Beard for their contributions.
Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself,
in no particular order.
llvm-svn: 133103
To determine what the indentation should be, a SourceLocation 'parentIndent' parameter is used that should be at
a source location with an indentation one degree lower than the given range.
llvm-svn: 129628
to use them instead of SourceRange. CharSourceRange is just a SourceRange
plus a bool that indicates whether the range has the end character resolved
or whether the end location is the start of the end token. While most of
the compiler wants to think of ranges that have ends that are the start of
the end token, the printf diagnostic stuff wants to highlight ranges within
tokens.
This is transparent to the diagnostic stuff. To start taking advantage of
the new capabilities, you can do something like this:
Diag(..) << CharSourceRange::getCharRange(Begin,End)
llvm-svn: 106338
SourceManager's getBuffer() (and similar) operations. This abstract
can be used to force callers to cope with errors in getBuffer(), such
as missing files and changed files. Fix a bunch of callers to use the
new interface.
Add some very basic checks for file consistency (file size,
modification time) into ContentCache::getBuffer(), although these
checks don't help much until we've updated the main callers (e.g.,
SourceManager::getSpelling()).
llvm-svn: 98585
- Please accept my sincere apologies for the gratuitous elimination of code
duplication, manual string length counting, unnecessary strlen calls, etc.
llvm-svn: 79448
This is simple enough, but then I thought it would be nice to make PrintingPolicy
get a LangOptions so that various things can key off "bool" and "C++" independently.
This spiraled out of control. There are many fixme's, but I think things are slightly
better than they were before.
One thing that can be improved: CFG should probably have an ASTContext pointer in it,
which would simplify its clients.
llvm-svn: 74493
