| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 165810
|
| |
|
|
| |
llvm-svn: 165794
|
| |
|
|
|
|
| |
#undef only occurs if that submodule is imported.
llvm-svn: 165773
|
| |
|
|
|
|
|
| |
has none of its own. Factor in Doug's comments.
// rdar://12378793
llvm-svn: 165771
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
in c-index-test. index_enteredMainFile is not invoked when indexing a
module file.
llvm-svn: 165735
|
| |
|
|
|
|
| |
release+asserts.
llvm-svn: 165734
|
| |
|
|
| |
llvm-svn: 165732
|
| |
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 165712
|
| |
|
|
| |
llvm-svn: 165710
|
| |
|
|
|
|
|
|
|
| |
Support the following intrinsics:
_mm_cvtph_ps, _mm256_cvtph_ps, _mm_cvtps_ph, _mm256_cvtps_ph
rdar://12407875
llvm-svn: 165685
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
member operator(). PR14057.
llvm-svn: 165678
|
| |
|
|
|
|
|
|
| |
This time, actually uncomment the code that's supposed to fix the problem.
This reverts r165671 / 8ceb837585ed973dc36fba8dfc57ef60fc8f2735.
llvm-svn: 165676
|
| |
|
|
|
|
|
|
|
| |
auto x((unknown));
int& y = x;
would crash because we were not flagging 'x' as an invalid declaration here.
llvm-svn: 165675
|
| |
|
|
|
|
|
|
|
| |
in a category class method, don't read 'isa' pointer. Instead,
save the desired OBJC_METACLASS_$_ClassName in
__DATA,__objc_superrefs and read that without reading any
isa pointers. // rdar://12459358
llvm-svn: 165674
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
offsets."
Author: Jordan Rose <jordan_rose@apple.com>
Date: Wed Oct 10 21:31:21 2012 +0000
[analyzer] Treat fields of unions as having symbolic offsets.
This allows only one field to be active at a time in RegionStore.
This isn't quite the correct behavior for unions, but it at least
would handle the case of "value goes in, value comes out" from the
same field.
RegionStore currently has a number of places where any access to a union
results in UnknownVal being returned. However, it is clearly missing
some cases, or the original issue wouldn't have occurred. It is probably
now safe to remove those changes, but that's a potentially destabilizing
change that should wait for more thorough testing.
Fixes PR14054.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165660 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit cf9030e480f77ab349672f00ad302e216c26c92c.
llvm-svn: 165671
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows only one field to be active at a time in RegionStore.
This isn't quite the correct behavior for unions, but it at least
would handle the case of "value goes in, value comes out" from the
same field.
RegionStore currently has a number of places where any access to a union
results in UnknownVal being returned. However, it is clearly missing
some cases, or the original issue wouldn't have occurred. It is probably
now safe to remove those changes, but that's a potentially destabilizing
change that should wait for more thorough testing.
Fixes PR14054.
llvm-svn: 165660
|
| |
|
|
| |
llvm-svn: 165653
|
| |
|
|
|
|
|
|
|
|
| |
methods looking for documentation on a particular base
class inherited by any method that overrides the base class.
In case of redeclaration, as when objc method is defined
in the implementation, it also looks up for documentation
in class/class extension being redeclared.
llvm-svn: 165643
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
...but do run them on user headers.
Previously, we were inconsistent here: non-path-sensitive checks on code
/bodies/ were only run in the main source file, but checks on
/declarations/ were run in /all/ headers. Neither of those is the
behavior we want.
Thanks to Sujit for pointing this out!
<rdar://problem/12454226>
llvm-svn: 165635
|
| |
|
|
|
|
|
| |
Reading from a weak property, casting the result, and assigning to a
strong pointer should still be considered safe.
llvm-svn: 165629
|
| |
|
|
|
|
|
|
| |
Then, switch users of PropertyIfSetterOrGetter and LookupPropertyDecl
(the latter by name) over to findPropertyDecl. This actually makes
-Wreceiver-is-weak a bit stronger than it was before.
llvm-svn: 165628
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Old algorithm:
1. See if the name looks like a getter or setter.
2. Use the name to look up a property in the current ObjCContainer
and all its protocols.
3. If the current container is an interface, also look in all categories
and superclasses (and superclass categories, and so on).
New algorithm:
1. See if the method is marked as a property accessor. If so, look through
all properties in the current container and find one that has a matching
selector.
2. Find all overrides of the method using ObjCMethodDecl's
getOverriddenMethods. This collects methods in superclasses and protocols
(as well as superclass categories, which isn't really necessary), and
checks if THEY are accessors. This part is not done recursively, since
getOverriddenMethods is already recursive.
This lets us handle getters and setters that do not match the property
names.
llvm-svn: 165627
|
| |
|
|
|
|
|
|
| |
constructor with invalid code.
rdar://12240916
llvm-svn: 165623
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The issue arises when coercing to/from types of different sizes. We need
to be certain that the allocation on either end has sufficient room for
the coerced type. When it doesn't, we need to make room, copy across,
and then proceed. PR11905 handled the case of storing function arguments
back into allocas in the function prolog, this patch handles the case of
setting up the function arguments in a call expression.
This is actually significantly simpler than the fix for PR11905. It ends
up being a trivial change to create a temporary alloca when the source
is too small and memcpy across. This should preserve the compile-time
fast-isel benefits of doing gep+load sequences and avoiding FCAs.
Reviewed by Benjamin and Evgeniy (who fixed PR11905).
llvm-svn: 165615
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
AAPCS ABI Section 7.1.4 [1] specifies that va_list
should be defined as struct __va_list { void *__ap;};
And in C++, it is defined in namespace std.
[1] http://infocenter.arm.com/help/topic
/com.arm.doc.ihi0042d/IHI0042D_aapcs.pdf
Patch by Weiming Zhao.
llvm-svn: 165609
|
| |
|
|
|
|
| |
non-positive value.
llvm-svn: 165583
|
| |
|
|
| |
llvm-svn: 165581
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MacroInfo*. Instead of simply dumping an offset into the current file,
give each macro definition a proper ID with all of the standard
modules-remapping facilities. Additionally, when a macro is modified
in a subsequent AST file (e.g., #undef'ing a macro loaded from another
module or from a precompiled header), provide a macro update record
rather than rewriting the entire macro definition. This gives us
greater consistency with the way we handle declarations, and ties
together macro definitions much more cleanly.
Note that we're still not actually deserializing macro history (we
never were), but it's far easy to do properly now.
llvm-svn: 165560
|
| |
|
|
|
|
|
| |
I think our general framework for parser pragmas needs a bit more work,
but I'm not planning on working on it at the moment.
llvm-svn: 165558
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
clang itself. This dates back to clang's early days and while it looks like
some of it is still used (for kext for example), other parts are probably dead.
Remove the -ccc-clang-archs option and associated code. I don't think there
is any remaining setup where clang doesn't support an architecture but it can
expect an working gcc cross compiler to be available.
A nice side effect is that tests no longer need to differentiate architectures
that are included in production builds of clang and those that are not.
llvm-svn: 165545
|
| |
|
|
|
|
| |
of the checks fails.
llvm-svn: 165536
|
| |
|
|
|
|
|
| |
options when clang invokes cc1plus for i386 kexts.
rdar://12459188
llvm-svn: 165534
|
| |
|
|
|
|
|
|
|
|
| |
whether that function/method already has a body (loaded from some
other AST file), as introduced in r165137. Delay this check until
after the redeclaration chains have been wired up.
While I'm here, make the loading of method bodies lazy.
llvm-svn: 165513
|
| |
|
|
|
|
|
|
|
|
|
|
| |
write out the macro history for that macro. Similarly, we need to cope
with reading a macro definition that has been #undef'd.
Take advantage of this new ability so that global code-completion
results can refer to #undef'd macros, rather than losing them
entirely. For multiply defined/#undef'd macros, we will still get the
wrong result, but it's better than getting no result.
llvm-svn: 165502
|
| |
|
|
|
|
| |
canonical method; avoid storing them again for an out-of-line definition.
llvm-svn: 165472
|
| |
|
|
|
|
| |
contexts. <rdar://problem/12453134>
llvm-svn: 165462
|