| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
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!
llvm-svn: 174576
|
|
|
|
|
|
| |
brought into 'clang' namespace by clang/Basic/LLVM.h
llvm-svn: 172323
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
which a particular declaration resides. Use this information to
customize the "definition of 'blah' must be imported from another
module" diagnostic with the module the user actually has to
import. Additionally, recover by importing that module, so we don't
complain about other names in that module.
Still TODO: coming up with decent Fix-Its for these cases, and expand
this recovery approach for other name lookup failures.
llvm-svn: 172290
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
per review discussion in r170365
This does limit these typedefs to being sequences, but no current usage
requires them to be contiguous (we could expand this to a more general
iterator pair range concept at some point).
Also, it'd be nice if SmallVector were constructible directly from an ArrayRef
but this is a bit tricky since ArrayRef depends on SmallVectorBaseImpl for the
inverse conversion. (& generalizing over all range-like things, while nice,
would require some nontrivial SFINAE I haven't thought about yet)
llvm-svn: 170482
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
|
|
|
|
|
|
|
|
|
| |
pull in all the generated Attr code.
Required to pull some functions out of line, but this shouldn't have a perf impact.
No functionality change.
llvm-svn: 169092
|
|
|
|
| |
llvm-svn: 168564
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
isUsed. With this change"
It brought bunch of (possibly false) warnings.
llvm/unittests/VMCore/PassManagerTest.cpp:60:22: warning: variable 'ID' is not needed and will not be emitted [-Wunneeded-internal-declaration]
char ModuleNDNM::ID=0;
^
llvm/unittests/VMCore/PassManagerTest.cpp:86:22: warning: variable 'ID' is not needed and will not be emitted [-Wunneeded-internal-declaration]
char ModuleNDM2::ID=0;
^
llvm/unittests/VMCore/PassManagerTest.cpp:106:21: warning: variable 'ID' is not needed and will not be emitted [-Wunneeded-internal-declaration]
char ModuleDNM::ID=0;
^
llvm/unittests/VMCore/PassManagerTest.cpp:217:16: warning: variable 'initcount' is not needed and will not be emitted [-Wunneeded-internal-declaration]
int LPass::initcount=0;
^
llvm/unittests/VMCore/PassManagerTest.cpp:218:16: warning: variable 'fincount' is not needed and will not be emitted [-Wunneeded-internal-declaration]
int LPass::fincount=0;
^
llvm/unittests/VMCore/PassManagerTest.cpp:259:16: warning: variable 'inited' is not needed and will not be emitted [-Wunneeded-internal-declaration]
int BPass::inited=0;
^
llvm/unittests/VMCore/PassManagerTest.cpp:260:16: warning: variable 'fin' is not needed and will not be emitted [-Wunneeded-internal-declaration]
int BPass::fin=0;
^
llvm/unittests/VMCore/PassManagerTest.cpp:283:24: warning: variable 'ID' is not needed and will not be emitted [-Wunneeded-internal-declaration]
char OnTheFlyTest::ID=0;
^
8 warnings generated.
llvm-svn: 168549
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"clang -cc1 -fsyntax-only" on the preprocessed output of
#define M extern int a;
#define M2 M M
#define M4 M2 M2
#define M8 M4 M4
#define M16 M8 M8
#define M32 M16 M16
#define M64 M32 M32
#define M128 M64 M64
#define M256 M128 M128
#define M512 M256 M256
#define M1024 M512 M512
#define M2048 M1024 M1024
#define M4096 M2048 M2048
#define M8192 M4096 M4096
#define M16384 M8192 M8192
M16384
goes from 2.994s to 1.416s. GCC is at 0.022s, so we still have a long way to go.
llvm-svn: 168519
|
|
|
|
| |
llvm-svn: 168515
|
|
|
|
| |
llvm-svn: 163546
|
|
|
|
|
|
|
| |
better. Fixes <rdar://problem/11466212>; the test (and back-ported
version of this code) were committed to LLDB in r160186.
llvm-svn: 160395
|
|
|
|
|
|
|
|
|
| |
places. I've turned this off for the GNU runtimes --- I don't know if
they support weak class import, but it's easy enough for them to opt in.
Also tweak a comment per review by Jordan.
llvm-svn: 158860
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
target Objective-C runtime down to the frontend: break this
down into a single target runtime kind and version, and compute
all the relevant information from that. This makes it
relatively painless to add support for new runtimes to the
compiler. Make the new -cc1 flag, -fobjc-runtime=blah-x.y.z,
available at the driver level as a better and more general
alternative to -fgnu-runtime and -fnext-runtime. This new
concept of an Objective-C runtime also encompasses what we
were previously separating out as the "Objective-C ABI", so
fragile vs. non-fragile runtimes are now really modelled as
different kinds of runtime, paving the way for better overall
differentiation.
As a sort of special case, continue to accept the -cc1 flag
-fobjc-runtime-has-weak, as a sop to PLCompatibilityWeak.
I won't go so far as to say "no functionality change", even
ignoring the new driver flag, but subtle changes in driver
semantics are almost certainly not intended.
llvm-svn: 158793
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
value_type
In addition, I've made the pointer and reference typedef 'void' rather than T*
just so they can't get misused. I would've omitted them entirely but
std::distance likes them to be there even if it doesn't use them.
This rolls back r155808 and r155869.
Review by Doug Gregor incorporating feedback from Chandler Carruth.
llvm-svn: 158104
|
|
|
|
|
|
|
| |
(trivially) make DeclContext::lookup()'s const version inlinable. Good
for 0.3% on <rdar://problem/11004361>.
llvm-svn: 156126
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reintroduce lazy name lookup table building, ensuring that the lazy building step
produces the same lookup table that would be built by the eager step.
Avoid building a lookup table for the translation unit outside C++, even in cases
where we can't recover the contents of the table from the declaration chain on
the translation unit, since we're not going to perform qualified lookup into it
anyway. Continue to support lazily building such lookup tables for now, though,
since ASTMerge uses them.
In my tests, this performs very similarly to ToT with r152608 backed out, for C,
Obj-C and C++, and does not suffer from PR10447.
llvm-svn: 152905
|
|
|
|
|
|
|
|
|
| |
don't, and clean up the places that do it.
The change to ASTWriter is surprising, but the deleted code is a no-op as of
r152608.
llvm-svn: 152609
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The deferred lookup table building step couldn't accurately tell which Decls
should be included in the lookup table, and consequently built different tables
in some cases.
Fix this by removing lazy building of DeclContext name lookup tables. In
practice, the laziness was frequently not worthwhile in C++, because we
performed lookup into most DeclContexts. In C, it had a bit more value,
since there is no qualified lookup.
In the place of lazy lookup table building, we simply don't build lookup tables
for function DeclContexts at all. Such name lookup tables are not useful, since
they don't capture the scoping information required to correctly perform name
lookup in a function scope.
The resulting performance delta is within the noise on my testing, but appears
to be a very slight win for C++ and a very slight loss for C. The C performance
can probably be recovered (if it is a measurable problem) by avoiding building
the lookup table for the translation unit.
llvm-svn: 152608
|
|
|
|
|
|
|
|
|
|
| |
(Lex to AST).
The member variable is always "LangOpts" and the member function is always "getLangOpts".
Reviewed by Chris Lattner
llvm-svn: 152536
|
|
|
|
|
|
|
|
| |
invalid ParmVarDecls.
Part of rdar://11007039.
llvm-svn: 152437
|
|
|
|
|
|
| |
bool. Ugh.
llvm-svn: 152062
|
|
|
|
| |
llvm-svn: 151152
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
arguments. There are two aspects to this:
- Make sure that when marking the declarations referenced in a
default argument, we don't try to mark local variables, both because
it's a waste of time and because the semantics are wrong: we're not
in a place where we could capture these variables again even if it
did make sense.
- When a lambda expression occurs in a default argument of a
function template, make sure that the corresponding closure type is
considered dependent, so that it will get properly instantiated. The
second bit is a bit of a hack; to fix it properly, we may have to
rearchitect our handling of default arguments, parsing them only
after creating the function definition. However, I'd like to
separate that work from the lambdas work.
llvm-svn: 151076
|
|
|
|
|
|
|
|
|
| |
the ASTReaderDecl
directly; they internally call Decl::getASTContext() which may crash if a declaration context
parent is still deserializing.
llvm-svn: 150137
|
|
|
|
| |
llvm-svn: 148577
|
|
|
|
|
|
| |
This allows -Wswitch-enum to find switches that need updating when these enums are modified.
llvm-svn: 148281
|
|
|
|
|
|
|
|
|
|
|
|
| |
we have a redeclarable type, and only use the new virtual versions
(getPreviousDeclImpl() and getMostRecentDeclImpl()) when we don't have
that type information. This keeps us from penalizing users with strict
type information (and is the moral equivalent of a "final" method).
Plus, settle on the names getPreviousDecl() and getMostRecentDecl()
throughout.
llvm-svn: 148187
|
|
|
|
|
|
|
|
|
| |
modules. Teach name lookup into namespaces to search in each of the
merged DeclContexts as well as the (now-primary) DeclContext. This
supports the common case where two different modules put something
into the same namespace.
llvm-svn: 147778
|
|
|
|
|
|
|
|
|
|
|
|
| |
to Redeclarable<NamespaceDecl>, so that we benefit from the improveed
redeclaration deserialization and merging logic provided by
Redeclarable<T>. Otherwise, no functionality change.
As a drive-by fix, collapse the "inline" bit into the low bit of the
original namespace/anonymous namespace, saving 8 bytes per
NamespaceDecl on x86_64.
llvm-svn: 147729
|
|
|
|
|
|
|
|
| |
into the two unused lower bits of the NextDeclInContext link, dropping
the number of bits in Decl down to 32, and saving 8 bytes per
declaration on x86-64.
llvm-svn: 147660
|
|
|
|
|
|
| |
some code in Clang expects 8-byte alignment of declarations.
llvm-svn: 147626
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
storage for the global declaration ID. Declarations that are parsed
(rather than deserialized) are unaffected, so the number of
declarations that pay this cost tends to be relatively small (since
relatively few declarations are ever deserialized).
This replaces a largish DenseMap within the AST reader. It's not
strictly a win in terms of memory use---not every declaration was
added to that DenseMap in the first place---but it's cleaner to have
this information available for every deserialized declaration, so that
future clients can rely on it.
llvm-svn: 147617
|
|
|
|
|
|
|
| |
go through a central allocation routine
Decl::AllocateDeserializedDecl(). No actual functionality change (yet).
llvm-svn: 147614
|
|
|
|
|
|
| |
ObjCProtocolDecl modules forward declarations properly.
llvm-svn: 147415
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for Objective-C protocols, including:
- Using the first declaration as the canonical declaration
- Using the definition as the primary DeclContext
- Making sure that all declarations have a pointer to the definition
data, and that we know which declaration is the definition
- Serialization support for redeclaration chains and for adding
definitions to already-serialized declarations.
However, note that we're not taking advantage of much of this code
yet, because we're still re-using ObjCProtocolDecls.
llvm-svn: 147410
|
|
|
|
|
|
|
| |
covers both declarations (@class) and definitions (@interface) of an
Objective-C class.
llvm-svn: 147299
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
redeclaration chain for Objective-C classes, including:
- Using the first declaration as the canonical declaration.
- Using the definition as the primary DeclContext
- Making sure that all declarations have a pointer to the definition
data, and the definition knows that it is the definition.
- Serialization support for when a definition gets added to a
declaration that comes from an AST file.
However, note that we're not taking advantage of much of this code
yet, because we're still re-using ObjCInterfaceDecls.
llvm-svn: 146667
|
|
|
|
|
|
| |
// rdar://10095131
llvm-svn: 146304
|
|
|
|
|
|
|
| |
implicitly generated in a translation unit. Modules will need this
information to identify the actual imports that occurred.
llvm-svn: 145734
|
|
|
|
|
|
|
|
| |
__import_module__ std.vector;
in the AST.
llvm-svn: 145725
|
|
|
|
| |
llvm-svn: 144094
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
property references to use a new PseudoObjectExpr
expression which pairs a syntactic form of the expression
with a set of semantic expressions implementing it.
This should significantly reduce the complexity required
elsewhere in the compiler to deal with these kinds of
expressions (e.g. IR generation's special l-value kind,
the static analyzer's Message abstraction), at the lower
cost of specifically dealing with the odd AST structure
of these expressions. It should also greatly simplify
efforts to implement similar language features in the
future, most notably Managed C++'s properties and indexed
properties.
Most of the effort here is in dealing with the various
clients of the AST. I've gone ahead and simplified the
ObjC rewriter's use of properties; other clients, like
IR-gen and the static analyzer, have all the old
complexity *and* all the new complexity, at least
temporarily. Many thanks to Ted for writing and advising
on the necessary changes to the static analyzer.
I've xfailed a small diagnostics regression in the static
analyzer at Ted's request.
llvm-svn: 143867
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
addDeclInternal(). This function suppresses any
calls to FindExternalVisibleDeclsByName() while
a Decl is added to a DeclContext. This behavior
is required for the ASTImporter, because in the
case of the LLDB client the ASTImporter would be
called recursively to import the visible decls,
which leads to assertions because the recursive
call is seeing partially-formed types.
I also modified the ASTImporter to use
addDeclInternal() in all places where it would
otherwise use addDecl(). This fix should not
affect the rest of Clang, passes Clang's
testsuite, and fixes several serious LLDB bugs.
llvm-svn: 142634
|
|
|
|
|
|
|
|
|
|
| |
avoids loading data from an external source, since those lookups were
causing some "interesting" recursion in LLDB.
This code is not efficient. I plan to remedy this inefficiency in a
follow-up commit.
llvm-svn: 142023
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the fields if they are already loaded, just ignore them when we are building
the chain in BuildDeclChain.
This fixes an lldb issue where fields were removed and not getting re-added
because lldb is based on ASTImporter adding decls to DeclContext and fields
were already added before by the ASTImporter.
We should really simplify the interaction between DeclContext <-> lldb
going forward..
rdar://10246067
llvm-svn: 141418
|
|
|
|
|
|
| |
a function/method/block it returns the corresponding DeclContext, otherwise it returns null.
llvm-svn: 140672
|
|
|
|
| |
llvm-svn: 140407
|
|
|
|
| |
llvm-svn: 140367
|
|
|
|
| |
llvm-svn: 139357
|