Age | Commit message (Collapse) | Author |
|
the absolute path.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127248 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127126 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127085 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the file contents with it.
Allow remapping a file by specifying another filename whose contents should be loaded if the original
file gets loaded. This allows to override files without having to create & load buffers in advance.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127052 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
template arguments. I believe that this is the last place in the AST
where we were storing a source range for a nested-name-specifier
rather than a proper nested-name-specifier location structure. (Yay!)
There is still a lot of cleanup to do in the TreeTransform, which
doesn't take advantage of nested-name-specifiers with source-location
information everywhere it could.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126844 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
template specialization types. There are still a few rough edges to
clean up with some of the parser actions dropping
nested-name-specifiers too early.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126776 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
nested-name-speciciers within elaborated type names, e.g.,
enum clang::NestedNameSpecifier::SpecifierKind
Fixes in this iteration include:
(1) Compute the type-source range properly for a dependent template
specialization type that starts with "template template-id ::", as
in a member access expression
dep->template f<T>::f()
This is a latent bug I triggered with this change (because now we're
checking the computed source ranges for dependent template
specialization types). But the real problem was...
(2) Make sure to set the qualifier range on a dependent template
specialization type appropriately. This will go away once we push
nested-name-specifier locations into dependent template
specialization types, but it was the source of the
valgrind errors on the buildbots.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126765 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
one.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126756 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
location information for elaborated types. *sigh*
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126753 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
information for qualifier type names throughout the parser to address
several problems.
The commit message from r126737:
Push nested-name-specifier source location information into elaborated
name types, e.g., "enum clang::NestedNameSpecifier::SpecifierKind".
Aside from the normal changes, this also required some tweaks to the
parser. Essentially, when we're looking at a type name (via
getTypeName()) specifically for the purpose of creating an annotation
token, we pass down the flag that asks for full type-source location
information to be stored within the returned type. That way, we retain
source-location information involving nested-name-specifiers rather
than trying to reconstruct that information later, long after it's
been lost in the parser.
With this change, test/Index/recursive-cxx-member-calls.cpp is showing
much improved results again, since that code has lots of
nested-name-specifiers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126748 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
buildbot breakage.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126746 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
name types, e.g., "enum clang::NestedNameSpecifier::SpecifierKind".
Aside from the normal changes, this also required some tweaks to the
parser. Essentially, when we're looking at a type name (via
getTypeName()) specifically for the purpose of creating an annotation
token, we pass down the flag that asks for full type-source location
information to be stored within the returned type. That way, we retain
source-location information involving nested-name-specifiers rather
than trying to reconstruct that information later, long after it's
been lost in the parser.
With this change, test/Index/recursive-cxx-member-calls.cpp is showing
much improved results again, since that code has lots of
nested-name-specifiers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126737 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
DependentNameTypeLoc. Teach the recursive AST visitor and libclang how to
walk DependentNameTypeLoc nodes.
Also, teach libclang about TypedefDecl source ranges, so that we get
those. The massive churn in test/Index/recursive-cxx-member-calls.cpp
is a good thing: we're annotating a lot more of this test correctly
now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126729 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
tag definitions. Also, add support for template instantiation of
NestedNameSpecifierLocs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126470 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
UnresolvedUsingValueDecl to use NestedNameSpecifierLoc rather than the
extremely-lossy NestedNameSpecifier/SourceRange pair it used to use,
improving source-location information.
Various infrastructure updates to support NestedNameSpecifierLoc:
- AST/PCH (de-)serialization
- Recursive AST visitor
- libclang traversal (including the first tests of this
functionality)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126459 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
way it keeps track of namespaces. Previously, we would map from the
namespace alias to its underlying namespace when building a
nested-name-specifier, losing source information in the process.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126358 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126299 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This fixes PR 8738, 9060 and 9132.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126069 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
whether Objective-C exceptions are enabled or not (they are by default).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126061 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
options, enabled OpenCL extensions and default FP_CONTRACT setting.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125589 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
another path.
Store in PCH the directory that the PCH was originally created in.
If a header file is not found at the path that we expect it to be and the PCH file
was moved from its original location, try to resolve the file by assuming that
header+PCH were moved together and the header is in the same place relative to the PCH.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125576 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
causing the deserialization of a large number of declarations when
writing the visible-updates record for the translation unit in C. This
takes us from:
*** AST File Statistics:
2 stat cache hits
6 stat cache misses
1/64463 source location entries read (0.001551%)
15606/16956 types read (92.038216%)
59266/89334 declarations read (66.342041%)
38952/61393 identifiers read (63.446976%)
0/7778 selectors read (0.000000%)
24192/34644 statements read (69.830276%)
388/8809 macros read (4.404586%)
2095/5189 lexical declcontexts read (40.373867%)
0/4587 visible declcontexts read (0.000000%)
0/7716 method pool entries read (0.000000%)
0 method pool misses
to
*** AST File Statistics:
2 stat cache hits
6 stat cache misses
1/64463 source location entries read (0.001551%)
26/16956 types read (0.153338%)
18/89334 declarations read (0.020149%)
145/61393 identifiers read (0.236183%)
0/7778 selectors read (0.000000%)
21/34644 statements read (0.060617%)
0/8809 macros read (0.000000%)
0/5189 lexical declcontexts read (0.000000%)
0/4587 visible declcontexts read (0.000000%)
0/7716 method pool entries read (0.000000%)
0 method pool misses
when generating a chained PCH for a header that #includes Cocoa.h
(from a PCH file) and adds one simple function declaration. The
generated PCH file is now only 9580 bytes (down from > 2MB).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125326 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
we would deserialize all of the macro definitions we knew about while
serializing the macro definitions at the end of the AST/PCH file. Even
though we skipped most of them (since they were unchanged), it's still
a performance problem.
Now, we do the standard AST/PCH chaining trick: watch what identifiers
are deserialized as macro names, and consider only those identifiers
(along with macro definitions that have been deserialized/written in
the source) when serializing the preprocessor state.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125324 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
macro definitions by macro name first. That way, we'll get a stable
ordering in the AST/PCH file.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125297 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
AST/PCH files more lazy:
- Don't preload all of the file source-location entries when reading
the AST file. Instead, load them lazily, when needed.
- Only look up header-search information (whether a header was already
#import'd, how many times it's been included, etc.) when it's needed
by the preprocessor, rather than pre-populating it.
Previously, we would pre-load all of the file source-location entries,
which also populated the header-search information structure. This was
a relatively minor performance issue, since we would end up stat()'ing
all of the headers stored within a AST/PCH file when the AST/PCH file
was loaded. In the normal PCH use case, the stat()s were cached, so
the cost--of preloading ~860 source-location entries in the Cocoa.h
case---was relatively low.
However, the recent optimization that replaced stat+open with
open+fstat turned this into a major problem, since the preloading of
source-location entries would now end up opening those files. Worse,
those files wouldn't be closed until the file manager was destroyed,
so just opening a Cocoa.h PCH file would hold on to ~860 file
descriptors, and it was easy to blow through the process's limit on
the number of open file descriptors.
By eliminating the preloading of these files, we neither open nor stat
the headers stored in the PCH/AST file until they're actually needed
for something. Concretely, we went from
*** HeaderSearch Stats:
835 files tracked.
364 #import/#pragma once files.
823 included exactly once.
6 max times a file is included.
3 #include/#include_next/#import.
0 #includes skipped due to the multi-include optimization.
1 framework lookups.
0 subframework lookups.
*** Source Manager Stats:
835 files mapped, 3 mem buffers mapped.
37460 SLocEntry's allocated, 11215575B of Sloc address space used.
62 bytes of files mapped, 0 files with line #'s computed.
with a trivial program that uses a chained PCH including a Cocoa PCH
to
*** HeaderSearch Stats:
4 files tracked.
1 #import/#pragma once files.
3 included exactly once.
2 max times a file is included.
3 #include/#include_next/#import.
0 #includes skipped due to the multi-include optimization.
1 framework lookups.
0 subframework lookups.
*** Source Manager Stats:
3 files mapped, 3 mem buffers mapped.
37460 SLocEntry's allocated, 11215575B of Sloc address space used.
62 bytes of files mapped, 0 files with line #'s computed.
for the same program.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125286 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125217 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125216 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
record away from the core processor record. The tangling of these two
data structures led to some inefficiencies (e.g., deserializing all
of the detailed preprocessing record when we didn't need it, such as
while performing code completion) along with some unnecessary
ugliness.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125117 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
format, so that llvm-bcanalyzer knows about all of the various record
kinds.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125086 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
and probably only works for very basic use cases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@124970 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@124661 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- Add ref-qualifiers to the type system; they are part of the
canonical type. Print & profile ref-qualifiers
- Translate the ref-qualifier from the Declarator chunk for
functions to the function type.
- Diagnose mis-uses of ref-qualifiers w.r.t. static member
functions, free functions, constructors, destructors, etc.
- Add serialization and deserialization of ref-qualifiers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@124281 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@124122 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@124041 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Inheritable attributes on declarations may be inherited by any later
redeclaration at merge time. By contrast, a non-inheritable attribute
will not be inherited by later redeclarations. Non-inheritable
attributes may be semantically analysed early, allowing them to
influence the redeclaration/overloading process.
Before this change, the "overloadable" attribute received special
handling to be treated as non-inheritable, while all other attributes
were treated as inheritable. This patch generalises the concept,
while removing a FIXME. Some CUDA location attributes are also marked
as non-inheritable in order to support special overloading semantics
(to be introduced in a later patch).
The patch introduces a new Attr subclass, InheritableAttr, from
which all inheritable attributes derive. Non-inheritable attributes
simply derive from Attr.
N.B. I did not review every attribute to determine whether it should
be marked non-inheritable. This can be done later on an incremental
basis, as this change does not affect default functionality.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@123959 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
template template parameter pack that cannot be fully expanded because
its enclosing pack expansion could not be expanded. This form of
TemplateName plays the same role as SubstTemplateTypeParmPackType and
SubstNonTypeTemplateParmPackExpr do for template type parameter packs
and non-type template parameter packs, respectively.
We should now handle these multi-level pack expansion substitutions
anywhere. The largest remaining gap in our variadic-templates support
is that we cannot cope with non-type template parameter packs whose
type is a pack expansion.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@123521 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@123510 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
number of expansions, when we know it, and propagate that information
through Sema.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@123493 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
warning flags.
Addresses rdar://8435969&8852495
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@123462 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
expansion, when it is known due to the substitution of an out
parameter pack. This allows us to properly handle substitution into
pack expansions that involve multiple parameter packs at different
template parameter levels, even when this substitution happens one
level at a time (as with partial specializations of member class
templates and the signatures of member function templates).
Note that the diagnostic we provide when there is an arity mismatch
between an outer parameter pack and an inner parameter pack in this
case isn't as clear as the normal diagnostic for an arity
mismatch. However, this doesn't matter because these cases are very,
very rare and (even then) only typically occur in a SFINAE context.
The other kinds of pack expansions (expression, template, etc.) still
need to support optional tracking of the number of expansions, and we
need the moral equivalent of SubstTemplateTypeParmPackType for
substituted argument packs of template template and non-type template
parameters.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@123448 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
involve template parameter packs at multiple template levels that
occur within the signatures members of class templates (and partial
specializations thereof). This is a work-in-progress that is deficient
in several ways, notably:
- It only works for template type parameter packs, but we need to
also support non-type template parameter packs and template template
parameter packs.
- It doesn't keep track of the lengths of the substituted argument
packs in the expansion, so it can't properly diagnose length
mismatches.
However, this is a concrete step in the right direction.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@123425 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
more accurate, and makes it make sense for it to hold a delegating constructor
call.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@123084 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Fix an unexpected hickup caused by exceeding size of
generated table (and a misleading comment). Improve
on help message for -fapple-kext.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@123003 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The initial TreeTransform is a cop-out, but it's more-or-less equivalent
to what we were doing before, or rather what we're doing now and might
eventually stop doing in favor of using this type.
I am simultaneously intrigued by the possibilities of rebuilding a
dependent Attri
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122942 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
expansions with something that is easier to use correctly: a new
template argment kind, rather than a bit on an existing kind. Update
all of the switch statements that deal with template arguments, fixing
a few latent bugs in the process. I"m happy with this representation,
now.
And, oh look! Template instantiation and deduction work for template
template argument pack expansions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122896 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
for template template argument pack expansions. This allows fun such
as:
template<template<class> class ...> struct apply_impl { /*...*/ };
template<template<class> class ...Metafunctions> struct apply {
typedef typename apply_impl<Metafunctions...>::type type;
};
However, neither template argument deduction nor template
instantiation is implemented for template template argument packs, so
this functionality isn't useful yet.
I'll probably replace the encoding of template template
argument pack expansions in TemplateArgument so that it's harder to
accidentally forget about the expansion. However, this is a step in
the right general direction.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122890 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122782 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
to allow us to explicitly control whether or
not Objective-C properties are default synthesized.
Currently this feature only works when using
the -fobjc-non-fragile-abi2 flag (so there is
no functionality change), but we can now turn
off this feature without turning off all the features
coupled with -fobjc-non-fragile-abi2.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122519 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122340 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
pack expansions, e.g. given
template<typename... Types> struct tuple;
template<typename... Types>
struct tuple_of_refs {
typedef tuple<Types&...> types;
};
the type of the "types" typedef is a PackExpansionType whose pattern
is Types&.
This commit introduces support for creating pack expansions for
template type arguments, as above, but not for any other kind of pack
expansion, nor for any form of instantiation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122223 91177308-0d34-0410-b5e6-96231b3b80d8
|