| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
The ASTUnit needs to initialize an ASTWriter at the beginning of
parsing to fully handle serialization of a translation unit that
imports modules. Do this by introducing an option to enable it, which
corresponds to CXTranslationUnit_ForSerialization on the C API side.
llvm-svn: 165717
|
| |
|
|
|
|
|
|
|
| |
Currently, Objective-C does not support class properties, even though it
allows calling class methods with dot syntax.
No intended functionality change; purely optimization.
llvm-svn: 165716
|
| |
|
|
|
|
| |
and Native Client
llvm-svn: 165715
|
| |
|
|
| |
llvm-svn: 165712
|
| |
|
|
| |
llvm-svn: 165710
|
| |
|
|
| |
llvm-svn: 165705
|
| |
|
|
| |
llvm-svn: 165688
|
| |
|
|
|
|
|
|
|
| |
Support the following intrinsics:
_mm_cvtph_ps, _mm256_cvtph_ps, _mm_cvtps_ph, _mm256_cvtps_ph
rdar://12407875
llvm-svn: 165685
|
| |
|
|
|
|
|
| |
is no longer necessary, as well as the little bit of infrastructure in
the AST writer that used it.
llvm-svn: 165684
|
| |
|
|
| |
llvm-svn: 165683
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
macro history.
When deserializing macro history, we arrange history such that the
macros that have definitions (that haven't been #undef'd) and are
visible come at the beginning of the list, which is what the
preprocessor and other clients of Preprocessor::getMacroInfo()
expect. If additional macro definitions become visible later, they'll
be moved toward the front of the list. Note that it's possible to have
ambiguities, but we don't diagnose them yet.
There is a partially-implemented design decision here that, if a
particular identifier has been defined or #undef'd within the
translation unit, that definition (or #undef) hides any macro
definitions that come from imported modules. There's still a little
work to do to ensure that the right #undef'ing happens.
Additionally, we'll need to scope the update records for #undefs, so
they only kick in when the submodule containing that update record
becomes visible.
llvm-svn: 165682
|
| |
|
|
|
|
| |
CLANG_ANALYZER_EXEC.
llvm-svn: 165681
|
| |
|
|
| |
llvm-svn: 165679
|
| |
|
|
|
|
| |
member operator(). PR14057.
llvm-svn: 165678
|