| Age | Commit message (Collapse) | Author |
|---|
|
a property, the -Wdirect-ivar-access should not warn when
accessing the property's synthesized instance variable.
// rdar://13142820
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175195 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175161 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175159 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The code generation stuff is going to set attributes on the functions it
generates. To do that it needs the target options. Pass them through.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175141 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
I added hasCLanguageLinkage while fixing some language linkage bugs some
time ago so that I wouldn't have to check all users of isExternC. It turned
out to be a much longer detour than expected, but this patch finally
merges the two again. The isExternC function now implements just the
standard notion of having C language linkage.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175119 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
some cases where functions with no language linkage were being treated as having
C language linkage. In particular, don't warn in
extern "C" {
static NonPod foo();
}
Since getLanguageLinkage checks the language linkage, the linkage computation
cannot use the language linkage. Break the loop by checking just the context
in the linkage computation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175117 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This has so far been disabled for Google style, but should be done
before breaking at nested name specifiers or in template parameters.
Before (in Google style):
template <typename T>
aaaaaaaa::aaaaa::aaaaaa<T, aaaaaaaaaaaaaaaaaaaaaaaaa> aaaaaaaaaaaaaaaaaaaaaaaa<
T>::aaaaaaa() {}
After:
template <typename T>
aaaaaaaa::aaaaa::aaaaaa<T, aaaaaaaaaaaaaaaaaaaaaaaaa>
aaaaaaaaaaaaaaaaaaaaaaaa<T>::aaaaaaa() {}
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175074 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Adding overloads of allOf accepting 4 and 5 arguments.
Reviewer: klimek
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174967 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
lexical storage but not visible storage' case in C++. It's unclear whether we
even need the special-case handling for C++, since it seems to be working
around our not serializing a lookup table for the TU in C. But in any case,
the assertion is incorrect.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174931 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Patch by Joey Gouly!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174928 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
declarations if we didn't have a lookup map when the external decls were added.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174906 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174862 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the "nonatomic" attribute in property redeclaration
in class extension. Also, improved on diagnostics in
this area while at it. // rdar://13156292
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174821 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174811 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
These are causing assertions on some MSVC builds.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174805 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
property.
There's no need to refer to the @implementation at all.
Fixes <rdar://problem/13186515>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174802 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
visible.
The basic problem here is that a given translation unit can use
forward declarations to form pointers to a given type, say,
class X;
X *x;
and then import a module that includes a definition of X:
import XDef;
We will then fail when attempting to access a member of X, e.g.,
x->method()
because the AST reader did not know to look for a default of a class
named X within the new module.
This implementation is a bit of a C-centric hack, because the only
definitions that can have this property are enums, structs, unions,
Objective-C classes, and Objective-C protocols, and all of those are
either visible at the top-level or can't be defined later. Hence, we
can use the out-of-date-ness of the name and the identifier-update
mechanism to force the update.
In C++, we will not be so lucky, and will need a more advanced
solution, because the definitions could be in namespaces defined in
two different modules, e.g.,
// module 1
namespace N { struct X; }
// module 2
namespace N { struct X { /* ... */ }; }
One possible implementation here is for C++ to extend the information
associated with each identifier table to include the declaration IDs
of any definitions associated with that name, regardless of
context. We would have to eagerly load those definitions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174794 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Add warnings under -Wc++11-compat, -Wc++98-compat, and -Wc99-compat when a
particular UCN is incompatible with a different standard, and -Wunicode when
a UCN refers to a surrogate character in C++03.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174788 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174782 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Nearly all of these changes are one-to-one replacements; the few that
aren't have to do with custom identifier validation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174768 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Rewriting the same predicates over and over again is bad for code size and
code maintainence. Using the functions in <ctype.h> is generally unsafe
unless they are specified to be locale-independent (i.e. only isdigit and
isxdigit).
The next commit will try to clean up uses of <ctype.h> functions within Clang.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174765 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
info in the translated code under -g only.
// rdar://13138170
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174684 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174683 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The checkPointerEscape callback previously did not specify how a
pointer escaped. This change includes an enum which describes the
different ways a pointer may escape. This enum is passed to the
checkPointerEscape callback when a pointer escapes. If the escape
is due to a function call, the call is passed. This changes
previous behavior where the call is passed as NULL if the escape
was due to indirectly invalidating the region the pointer referenced.
A patch by Branden Archer!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174677 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
consistency.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174645 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
OpenCL builtin functions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174630 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is a powerful tool when doing iterative refined matches,
where another match is started inside the match callback of the first
one; this allows for example to find out whether the node was in
the condition or body of its parent if-statement.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174605 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
restrictions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174601 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
name lookup has been performed in that context (this probably only happens in
C++).
1) Whenever we add names to a context, set a flag on it, and if we perform
lookup and discover that the context has had a lookup table built but has the
flag set, update all entries in the lookup table with additional names from
the external source.
2) When marking a DeclContext as having external visible decls, mark the
context in which lookup is performed, not the one we are adding. These won't
be the same if we're adding another copy of a pre-existing namespace.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174577 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
if it found any decls, rather than returning a list of found decls. This
removes a returning-ArrayRef-to-deleted-storage bug from
MultiplexExternalSemaSource (in code not exercised by any of the clang
binaries), reduces the work required in the found-no-decls case with PCH, and
importantly removes the need for DeclContext::lookup to be reentrant.
No functionality change intended!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174576 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
modules.
The use of this flag enables a modules optimization where a given set
of macros can be labeled as "ignored" by the modules
system. Definitions of those macros will be completely ignored when
building the module hash and will be stripped when actually building
modules. The overall effect is that this flag can be used to
drastically reduce the number of
Eventually, we'll want modules to tell us what set of macros they
respond to (the "configuration macros"), and anything not in that set
will be excluded. However, that requires a lot of per-module
information that must be accurate, whereas this option can be used
more readily.
Fixes the rest of <rdar://problem/13165109>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174560 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This can happen when one abuses precompiled headers by passing more -D
options when using a precompiled hedaer than when it was built. This
is intentionally permitted by precompiled headers (and is exploited by
some build environments), but causes problems for modules.
First part of <rdar://problem/13165109>, detecting when something when
horribly wrong.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174554 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is in preparation for adding other overloaded matchers. This change
alone is a net win in LOC.
I went through all matchers and looked whether we could now encode them
as macro, or simplify them with the matcher atoms that were not
available before.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174540 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This was GCC's option to turn on UCN support, which we always have on now
in C99 and C++ modes.
Additionally, mark the -fno-extended-identifiers option as unsupported,
since we don't support disabling UCNs in C99 and C++ modes.
PR11538
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174530 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
With this patch, clang-format can analyze the input file for two
properties:
1. Is "int *a" or "int* a" more common.
2. Are non-C++03 constructs used, e.g. A<A<A>>.
With Google-style, clang-format will now use the more common style for
(1) and format C++03 compatible, unless it finds C++11 constructs in the
input.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174504 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
A very common use case is to search for the first occurrence of
a certain node that is a descendant of another node. In that
case, selectFirst significantly simplifies the code at the client side.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174499 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is a more natural order of evaluation, and it is very important
for visualization in the static analyzer. Within Xcode, the arrows
will not jump from right to left, which looks very visually jarring.
It also provides a more natural location for dataflow-based diagnostics.
Along the way, we found a case in the analyzer diagnostics where we
needed to indicate that a variable was "captured" by a block.
-fsyntax-only timings on sqlite3.c show no visible performance change,
although this is just one test case.
Fixes <rdar://problem/13016513>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174447 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174434 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the DWARF5 split dwarf proposal.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174349 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
vector initialization. Patch by John Stratton!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174339 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174337 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
We found that findAll has been implemented incorrectly multiple times
by various people using the matchers. To prevent further wasted
development effort, it makes sense to add it as convenience matcher
implemented as eachOf(m, forEachDescendant(m)).
This patch also updates the docs with the new matchers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174320 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
eachOf gives closure on the forEach and forEachDescendant matchers.
Before, it was impossible to implement a findAll matcher, as matching
the node or any of its descendants was not expressible (since anyOf
only triggers the first match).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174315 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This combines several changes:
* Calculation token type (e.g. for * and &) in the AnnotatingParser.
* Calculate the scope binding strength in the AnnotatingParser.
* Let <> and [] scopes bind stronger than () and {} scopes.
* Add minimal debugging output.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174307 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174287 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174282 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
...again. The problem has not been fixed and our internal buildbot is still
getting hangs.
This reverts r174212, originally applied in r173951, then reverted in r174069.
Will not re-apply until the entire project analyzes successfully on my
local machine.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174265 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
designator" diagnostic with more correct and more human-friendly "cannot take
address of rvalue of type 'T'".
For the case of & &T::f, provide a custom diagnostic, rather than unhelpfully
saying "cannot take address of rvalue of type '<overloaded function type>'".
For the case of &array_temporary, treat it just like a class temporary
(including allowing it as an extension); the existing diagnostic wording
for the class temporary case works fine.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174262 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Inlining these functions is essential for correctness. We often have
cases where we do not inline calls. For example, the shallow mode and
when reanalyzing previously inlined ObjC methods as top level.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174245 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
says, but that's a defect (to be filed). "Cls::purevfn()" is still an odr use.
Also fixes a bug that caused us to not mark the function referenced just
because we didn't want to mark it odr used.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174242 91177308-0d34-0410-b5e6-96231b3b80d8
|
