| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 165835
|
| |
|
|
| |
llvm-svn: 165834
|
| |
|
|
|
|
| |
Patch by Grzegorz Jablonski.
llvm-svn: 165832
|
| |
|
|
| |
llvm-svn: 165829
|
| |
|
|
|
|
| |
declarations.
llvm-svn: 165826
|
| |
|
|
|
|
| |
reimplemented in the AsmParser where it belongs.
llvm-svn: 165825
|
| |
|
|
| |
llvm-svn: 165822
|
| |
|
|
|
|
|
| |
or directories, to make sure that they are identifiers that are not
keywords in any dialect. Fixes <rdar://problem/12489495>.
llvm-svn: 165821
|
| |
|
|
| |
llvm-svn: 165819
|
| |
|
|
| |
llvm-svn: 165818
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When suggesting "foo::bar" as a correction for "fob::bar" we mistakenly
replaced only "bar" with "foo::bar" producing "fob::foo::bar" which was broken.
This corrects that replacement in as many places as I could find & provides
test cases for all those cases I could find a test case for. There are a couple
that don't seem to be reachable (one looks entirely dead, the other just
doesn't seem to ever get called with a namespace to namespace change).
Review by Richard Smith ( http://llvm-reviews.chandlerc.com/D57 ).
llvm-svn: 165817
|
| |
|
|
|
|
|
|
|
|
|
|
| |
For 64-bit PowerPC SVR4, an aggregate containing only one
floating-point field (float, double, or long double) must be passed in
a register as though just that field were present. This patch
addresses the issue during Clang code generation by specifying in the
ABIArgInfo for the argument that the underlying type is passed
directly in a register. The included test case verifies flat and
nested structs for the three data types.
llvm-svn: 165816
|
| |
|
|
| |
llvm-svn: 165815
|
| |
|
|
|
|
| |
No functional change.
llvm-svn: 165811
|
| |
|
|
| |
llvm-svn: 165810
|
| |
|
|
|
|
|
| |
overridden symbols. OK'ed off-line by Doug.
// rdar://12378793
llvm-svn: 165807
|
| |
|
|
| |
llvm-svn: 165797
|
| |
|
|
| |
llvm-svn: 165794
|
| |
|
|
| |
llvm-svn: 165793
|
| |
|
|
| |
llvm-svn: 165788
|
| |
|
|
|
|
| |
OSAtomicCompareAndSwap if the return type is not a boolean.
llvm-svn: 165774
|
| |
|
|
|
|
| |
#undef only occurs if that submodule is imported.
llvm-svn: 165773
|
| |
|
|
| |
llvm-svn: 165772
|
| |
|
|
|
|
|
| |
has none of its own. Factor in Doug's comments.
// rdar://12378793
llvm-svn: 165771
|
| |
|
|
|
|
|
| |
Updates to llvm/Support/Casting.h have rendered these classof()'s
irrelevant.
llvm-svn: 165770
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Somewhat troublingly, without this implemented, the check inside
isa_impl<> would silently use the parent's `classof()` when determining
whether it was okay to downcast from the parent to the child!
Bug analysis:
A build failure after removing the parent's `classof()` initially
alerted me to the bug, after which a little bit of thinking and reading
of the code identified the root cause.
The compiler could be made to prevent this bug from happening if there
were a way to ensure that in the code
template <typename To, typename From, typename Enabler = void>
struct isa_impl {
static inline bool doit(const From &Val) {
return To::classof(&Val);
}
};
that `To::classof` is actually inside the class `To`, and not in a base
class. I am not aware of a way to check this in C++. If there is a means
to perform that check, please bring it up on the list and this will be
fixed.
There is a high likelihood that there are other instances of this same
bug in the codebase.
llvm-svn: 165769
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This only applies if the type has a name. (we could potentially do something
crazy with decltype in C++11 to qualify members of unnamed types but that
seems excessive)
It might be nice to also suggest a fixit for "&this->i", "&foo->i",
and "&foo.i" but those expressions produce 'bound' member functions that have
a different AST representation & make error recovery a little trickier. Left
as future work.
llvm-svn: 165763
|
| |
|
|
| |
llvm-svn: 165762
|
| |
|
|
| |
llvm-svn: 165761
|
| |
|
|
| |
llvm-svn: 165760
|
| |
|
|
|
|
| |
reimplemented in the AsmParser where it belongs.
llvm-svn: 165752
|
| |
|
|
|
|
|
|
|
| |
now unused static helper function.
The test case needs to be remove temporarily until I can better filter memory
operands that aren't actual variable reference.
llvm-svn: 165751
|
| |
|
|
|
|
|
| |
only with modules, when two disjoint modules #define the same
identifier to different token sequences.
llvm-svn: 165746
|
| |
|
|
| |
llvm-svn: 165744
|
| |
|
|
|
|
| |
objc_atomicCompareAndSwap.
llvm-svn: 165743
|
| |
|
|
| |
llvm-svn: 165742
|
| |
|
|
| |
llvm-svn: 165741
|
| |
|
|
|
|
|
| |
in c-index-test. index_enteredMainFile is not invoked when indexing a
module file.
llvm-svn: 165735
|
| |
|
|
|
|
| |
release+asserts.
llvm-svn: 165734
|
| |
|
|
| |
llvm-svn: 165733
|
| |
|
|
| |
llvm-svn: 165732
|
| |
|
|
| |
llvm-svn: 165731
|
| |
|
|
|
|
| |
associated with deserializing macro history for an identifier.
llvm-svn: 165729
|
| |
|
|
| |
llvm-svn: 165727
|
| |
|
|
|
|
| |
per address space pointer sizes to be optimized correctly.
llvm-svn: 165726
|
| |
|
|
|
|
| |
Fix-up for r165718, should get the buildbots back online.
llvm-svn: 165723
|
| |
|
|
|
|
| |
with x86/ARM architecture
llvm-svn: 165722
|
| |
|
|
|
|
| |
Grosser.
llvm-svn: 165720
|
| |
|
|
|
|
|
|
|
|
| |
This is a "safe" pattern, or at least one that cannot be helped by using
a strong local variable. However, if the single read is within a loop,
it should /always/ be treated as potentially dangerous.
<rdar://problem/12437490>
llvm-svn: 165719
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, [foo weakProp] was not being treated the same as foo.weakProp.
Now, for every explicit message send, we check if it's a property access,
and if so, if the property is weak. Then for every assignment of a
message, we have to do the same thing again.
This is a potentially expensive increase because determining whether a
method is a property accessor requires searching through the methods it
overrides. However, without it -Warc-repeated-use-of-weak will miss cases
from people who prefer not to use dot syntax. If this turns out to be
too expensive, we can try caching the result somewhere, or even lose
precision by not checking superclass methods. The warning is off-by-default,
though.
<rdar://problem/12407765>
llvm-svn: 165718
|