| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
llvm-svn: 319595
|
| |
|
|
|
|
|
|
| |
Wasn't sure I could include ErrorHandling.h here, and evidently I wasn't
building this part (must've made the change using sed after getting
tired of fixing each compilation error individually).
llvm-svn: 291204
|
| |
|
|
|
|
|
|
|
| |
Also found/fixed one bug identified by this warning in
RenderScriptx86ABIFixups.cpp where a string literal was being used in an
effort to provide a name for an instruction/register, but was instead
being passed as the bool 'isVolatile' parameter.
llvm-svn: 291198
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:
Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):
find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;
The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.
Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.
llvm-svn: 280751
|
| |
|
|
|
|
|
|
| |
now they are.
<rdar://problem/27002247>
llvm-svn: 274037
|
| |
|
|
|
|
|
|
| |
Remove a couple of `default` cases from switches which are covered. This is
beneficial since it would allow the compiler to indicate when a new enum value
is added and the switch is not updated. Fixes some warnings from clang. NFC.
llvm-svn: 268756
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11404
llvm-svn: 242913
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary.
So I defined a new "lldb::offset_t" which should be used for all file offsets.
After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed.
Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections.
llvm-svn: 173463
|
| |
|
|
| |
llvm-svn: 137319
|
| |
|
|
|
|
| |
respectively.
llvm-svn: 128720
|
|
|
llvm-svn: 105619
|
