| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
Before:
< T extends B > T getInstance(Class<T> type);
After:
<T extends B> T getInstance(Class<T> type);
llvm-svn: 221124
|
|
|
|
|
|
|
|
|
|
| |
Before:
public static<R> ArrayList<R> get() {}
After:
public static <R> ArrayList<R> get() {}
llvm-svn: 221122
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
@SomeAnnotation()
abstract
class aaaaaaaaaaaa extends bbbbbbbbbbbbbbb implements cccccccccccc {
}
After:
@SomeAnnotation()
abstract class aaaaaaaaaaaa extends bbbbbbbbbbbbbbb
implements cccccccccccc {
}
llvm-svn: 221121
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
delete [] a -> b;
After:
delete[] a->b;
This fixes part of llvm.org/PR21419.
llvm-svn: 221114
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
class SomeClass {
enum SomeThing { ABC, CDE } void f() {
}
}
After:
class SomeClass {
enum SomeThing { ABC, CDE }
void f() {
}
}
This fixed llvm.org/PR21458.
llvm-svn: 221113
|
|
|
|
|
|
| |
This fixes llvm.org/PR21453.
llvm-svn: 221112
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
synchronized(mData) {
// ...
}
After:
synchronized (mData) {
// ...
}
This fixes llvm.org/PR21455.
llvm-svn: 221110
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
@Override
public Map < String,
? > getAll() {
// ...
}
After:
@Override
public Map<String, ?> getAll() {
// ...
}
This fixes llvm.org/PR21454.
llvm-svn: 221109
|
|
|
|
| |
llvm-svn: 221104
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
abstract class SomeClass extends SomeOtherClass implements
SomeInterface {}
After:
abstract class SomeClass extends SomeOtherClass
implements SomeInterface {}
llvm-svn: 221103
|
|
|
|
|
|
| |
Implement post-commit comment on r220989 from Eric Christopher.
llvm-svn: 221099
|
|
|
|
|
|
| |
names for these intrinsics.
llvm-svn: 221066
|
|
|
|
|
|
| |
for 0 before calling __builtin_ctz. Without this the optimizers may take advantage of the undefined behavior and produce incorrect results. LLVM itself still needs to be taught to merge the zero check into the llvm.cttz with defined zero behavior.
llvm-svn: 221065
|
|
|
|
|
|
| |
for 0 before calling __builtin_clz. Without this the optimizers may take advantage of the undefined behavior and produce incorrect results. LLVM itself still needs to be taught to merge the zero check into the llvm.ctlz with defined zero behavior.
llvm-svn: 221064
|
|
|
|
|
|
| |
No functionality change intended.
llvm-svn: 221043
|
|
|
|
|
|
|
| |
The ARM ABI virtual destructor thunks cannot be marked as 'returned'
because they return undef.
llvm-svn: 221042
|
|
|
|
|
|
| |
[-Winconsistent-missing-override]
llvm-svn: 221039
|
|
|
|
| |
llvm-svn: 221030
|
|
|
|
|
|
|
|
|
|
| |
It says there is a narrowing conversion when we assign it to an unsigned
3 bit bitfield.
Also, use unsigned instead of size_t for the Size field of the struct in
question. Otherwise they won't run together in MSVC or clang-cl.
llvm-svn: 221019
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The most complex aspect of the convention is the handling of homogeneous
vector and floating point aggregates. Reuse the homogeneous aggregate
classification code that we use on PPC64 and ARM for this.
This convention also has a C mangling, and we apparently implement that
in both Clang and LLVM.
Reviewed By: majnemer
Differential Revision: http://reviews.llvm.org/D6063
llvm-svn: 221006
|
|
|
|
|
|
|
|
| |
,-objcmt-migrate-property-dot-syntax, when migarting to use
property-dot syntax in place of messaging expression.
rdar://18839124
llvm-svn: 221001
|
|
|
|
| |
llvm-svn: 221000
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The Itanium ABI approach of using offset-to-top isn't possible with the
MS ABI, it doesn't have that kind of information lying around.
Instead, we do the following:
- Call the virtual deleting destructor with the "don't delete the object
flag" set. The virtual deleting destructor will return a pointer to
'this' adjusted to the most derived class.
- Call the global delete using the adjusted 'this' pointer.
Reviewers: rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5996
llvm-svn: 220993
|
|
|
|
|
|
|
| |
macros in user code when macros themselves are defined
in a system header. rdar://18295240
llvm-svn: 220992
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that we have initial support for VSX, we can begin adding
intrinsics for programmer access to VSX instructions. This patch
performs the necessary enablement in the front end, and tests it by
implementing intrinsics for minimum and maximum using the vector
double data type.
The main change in the front end is to no longer disallow "vector" and
"double" in the same declaration (lib/Sema/DeclSpec.cpp), but "vector"
and "long double" must still be disallowed. The new intrinsics are
accessed via vec_max and vec_min with changes in
lib/Headers/altivec.h. Note that for v4f32, we already access
corresponding VMX builtins, but with VSX enabled we should use the
forms that allow all 64 vector registers.
The new built-ins are defined in include/clang/Basic/BuiltinsPPC.def.
I've added a new test in test/CodeGen/builtins-ppc-vsx.c that is
similar to, but much smaller than, builtins-ppc-altivec.c. This
allows us to test VSX IR generation without duplicating CHECK lines
for the existing bazillion Altivec tests.
Since vector double is now legal when VSX is available, I've modified
the error message, and changed where we test for it and for vector
long double, since the target machine isn't visible in the old place.
This serendipitously removed a not-pertinent warning about 'long'
being deprecated when used with 'vector', when "vector long double" is
encountered and we just want to issue an error. The existing tests
test/Parser/altivec.c and test/Parser/cxx-altivec.cpp have been
updated accordingly, and I've added test/Parser/vsx.c to verify that
"vector double" is now legitimate with VSX enabled.
There is a companion patch for LLVM.
llvm-svn: 220989
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When we are adding field paddings for asan even an empty dtor has to remain in the code,
so we ignore -mconstructor-aliases if the paddings are going to be added.
Test Plan: added a test
Reviewers: rsmith, rnk, rafael
Reviewed By: rafael
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6038
llvm-svn: 220986
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
@SomeAnnotation("With some really looooooooooooooong text") private static final
long something = 0L;
void SomeFunction(@Nullable
String something) {}
After:
@SomeAnnotation("With some really looooooooooooooong text")
private static final long something = 0L;
void SomeFunction(@Nullable String something) {}
llvm-svn: 220984
|
|
|
|
|
|
| |
The style guide is changing..
llvm-svn: 220977
|
|
|
|
| |
llvm-svn: 220974
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reuse the PPC64 HVA detection algorithm for ARM and AArch64. This is a
nice code deduplication, since they are roughly identical. A few virtual
method extension points are needed to understand how big an HVA can be
and what element types it can have for a given architecture.
Also make the record expansion code work in the presence of non-virtual
bases.
Reviewed By: uweigand, asl
Differential Revision: http://reviews.llvm.org/D6045
llvm-svn: 220972
|
|
|
|
|
|
|
|
|
|
| |
Rather than executing this code only needed for an assertion even in a
non-asserts build, just roll the function into the assert. The assertion
text literally describes the two cases so it doesn't seem like this
benefits much from having a separate function (& have to hassle about
ifndef NDEBUG it out, etc)
llvm-svn: 220970
|
|
|
|
|
|
| |
they are not needed.
llvm-svn: 220966
|
|
|
|
|
|
| |
StorageClass is in the clang namespace.
llvm-svn: 220956
|
|
|
|
| |
llvm-svn: 220955
|
|
|
|
|
|
| |
name. Remove a typedef that matches an identical one in the clang namespace.
llvm-svn: 220954
|
|
|
|
|
|
| |
unit, allow the -O settings of the two compilations to differ.
llvm-svn: 220943
|
|
|
|
|
|
| |
rather than simply pretty-printing it.
llvm-svn: 220942
|
|
|
|
| |
llvm-svn: 220940
|
|
|
|
|
|
|
|
|
|
| |
The former name doesn't make sense, we are using this parameter for both .a and .dylib libraries.
No functional change.
http://reviews.llvm.org/D6040
llvm-svn: 220939
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of manually maintaining a flag indicating whether we're about to print
out the last child of the parent node (to determine whether we print "`" or
"|"), capture a callable to print that child and defer printing it until we
either see a next child or finish the parent.
No functionality change intended.
llvm-svn: 220930
|
|
|
|
|
|
|
|
|
| |
SanitizerOptions is not even a POD now, so having global variable of
this type, is not nice. Instead, provide a regular constructor and clear()
method, and let each CodeGenFunction has its own copy of SanitizerOptions
it uses.
llvm-svn: 220920
|
|
|
|
| |
llvm-svn: 220897
|
|
|
|
| |
llvm-svn: 220893
|
|
|
|
| |
llvm-svn: 220890
|
|
|
|
| |
llvm-svn: 220889
|
|
|
|
| |
llvm-svn: 220883
|
|
|
|
|
|
| |
Format.h doesn't use stack.
llvm-svn: 220879
|
|
|
|
| |
llvm-svn: 220877
|
|
|
|
|
|
|
| |
check the context ourselves when selectively allowing late-added
dll attributes on unused free functions and variables (PR20746)
llvm-svn: 220874
|
|
|
|
|
|
|
|
|
|
| |
This moves classes for storing and applying replacements to separate
files. These classes specifically are used by clang-format which doesn't
have any other dependencies on clangAST. Thereby, the size of
clang-format's binary can be cut roughly in half and its build time sped
up.
llvm-svn: 220867
|