I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line with a #include and let it re-sort things according to the precise
LLVM rules for include ordering baked into clang-format these days.
I've reverted a number of files where the results of sorting includes
isn't healthy. Either places where we have legacy code relying on
particular include ordering (where possible, I'll fix these separately)
or where we have particular formatting around #include lines that
I didn't want to disturb in this patch.
This patch is *entirely* mechanical. If you get merge conflicts or
anything, just ignore the changes in this patch and run clang-format
over your #include lines in the files.
Sorry for any noise here, but it is important to keep these things
stable. I was seeing an increasing number of patches with irrelevant
re-ordering of #include lines because clang-format was used. This patch
at least isolates that churn, makes it easy to skip when resolving
conflicts, and gets us to a clean baseline (again).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304787 91177308-0d34-0410-b5e6-96231b3b80d8
Because the current proposal does not include that member function,
and we are trying to keep in line with that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@248451 91177308-0d34-0410-b5e6-96231b3b80d8
Function static variables, typedefs and records (class, struct or union) declared inside
a lexical scope were associated with the function as their parent scope, rather than the
lexical scope they are defined or declared in.
This fixes PR19238
Patch by: amjad.aboud@intel.com
Differential Revision: http://reviews.llvm.org/D9758
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241153 91177308-0d34-0410-b5e6-96231b3b80d8
The patch is generated using this command:
tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
llvm/lib/
Thanks to Eugene Kosov for the original patch!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240137 91177308-0d34-0410-b5e6-96231b3b80d8
This default constructor is a bit weird. It left the range in an invalid
state. That might be reasonable so that you can construct a local
iterator range and assign to it based on some logic to compute the range
you want. If folks would like to support that use case, I can add it
back, but in 238-odd usages none have actually wanted to do this. ;]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225592 91177308-0d34-0410-b5e6-96231b3b80d8
One of many steps to generalize subprogram emission to both the DWO and
non-DWO sections (to emit -gmlt-like data under fission). Once the
functions are pushed down into DwarfCompileUnit some of the data
structures will be pushed at least into DwarfFile so that they can be
unique per-file, allowing emission to both files independently.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219345 91177308-0d34-0410-b5e6-96231b3b80d8
Move the iterators into the range the same way the range's ctor moves
them into the members.
Also remove some redundant top level parens in the return statement.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205993 91177308-0d34-0410-b5e6-96231b3b80d8
Convenience wrapper to make dealing with sub-ranges easier. Like the
iterator_range<> itself, if/when this sort of thing gets standards
blessing, it will be replaced by the official version.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205987 91177308-0d34-0410-b5e6-96231b3b80d8
proposed std::iterator_pair which was in committee suggested to move
toward std::iterator_range. There isn't a formal paper yet, but there
seems little disagreement within the committee at this point so it seems
fine to provide our own version in the llvm namespace so we can easily
build range adaptors for the numerous iterators in LLVM's interfaces.
Note that I'm not really comfortable advocating a crazed range-based
migration just yet. The range stuff is still in a great deal of flux in
C++ and the committee hasn't entirely made up its mind (afaict) about
how it will work. So I'm mostly trying to provide the minimal
functionality needed to make writing easy and convenient range adaptors
for range based for loops easy and convenient. ;]
Subsequent patches will use this across the fundamental IR types, where
there are iterator views.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202686 91177308-0d34-0410-b5e6-96231b3b80d8
