accompanying fixes to make it work today.
The core of this patch is to provide a link from a TemplateTypeParmType
back to the TemplateTypeParmDecl node which declared it. This in turn
provides much more precise information about the type, where it came
from, and how it functions for AST consumers.
To make the patch work almost a year after its first attempt, it needed
serialization support, and it now retains the old getName() interface.
Finally, it requires us to not attempt to instantiate the type in an
unsupported friend decl -- specifically those coming from template
friend decls but which refer to a specific type through a dependent
name.
A cleaner representation of the last item would be to build
FriendTemplateDecl nodes for these, storing their template parameters
etc, and to perform proper instantation of them like any other template
declaration. They can still be flagged as unsupported for the purpose of
access checking, etc.
This passed an asserts-enabled bootstrap for me, and the reduced test
case mentioned in the original review thread no longer causes issues,
likely fixed at somewhere amidst the 24k revisions that have elapsed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130628 91177308-0d34-0410-b5e6-96231b3b80d8
member function, i.e. something of the form 'x.f' where 'f' is a non-static
member function. Diagnose this in the general case. Some of the new diagnostics
are probably worse than the old ones, but we now get this right much more
universally, and there's certainly room for improvement in the diagnostics.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130239 91177308-0d34-0410-b5e6-96231b3b80d8
language options, and warn when reading an AST with a different value
for the bit.
There doesn't appear to be a good way to test this (commenting out
similar other language options doesn't break anything) but if folks have
suggestions on tests I'm happy to add them.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130071 91177308-0d34-0410-b5e6-96231b3b80d8
during deserialization from a precompiled header, and update all of
its callers to note when this problem occurs and recover (more)
gracefully. Fixes <rdar://problem/9119249>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@129839 91177308-0d34-0410-b5e6-96231b3b80d8
The idea is that you can create a VarDecl with an unknown type, or a
FunctionDecl with an unknown return type, and it will still be valid to
access that object as long as you explicitly cast it at every use. I'm
still going back and forth about how I want to test this effectively, but
I wanted to go ahead and provide a skeletal implementation for the LLDB
folks' benefit and because it also improves some diagnostic goodness for
placeholder expressions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@129065 91177308-0d34-0410-b5e6-96231b3b80d8
which versions of an OS provide a certain facility. For example,
void foo()
__attribute__((availability(macosx,introduced=10.2,deprecated=10.4,obsoleted=10.6)));
says that the function "foo" was introduced in 10.2, deprecated in
10.4, and completely obsoleted in 10.6. This attribute ties in with
the deployment targets (e.g., -mmacosx-version-min=10.1 specifies that
we want to deploy back to Mac OS X 10.1). There are several concrete
behaviors that this attribute enables, as illustrated with the
function foo() above:
- If we choose a deployment target >= Mac OS X 10.4, uses of "foo"
will result in a deprecation warning, as if we had placed
attribute((deprecated)) on it (but with a better diagnostic)
- If we choose a deployment target >= Mac OS X 10.6, uses of "foo"
will result in an "unavailable" warning (in C)/error (in C++), as
if we had placed attribute((unavailable)) on it
- If we choose a deployment target prior to 10.2, foo() is
weak-imported (if it is a kind of entity that can be weak
imported), as if we had placed the weak_import attribute on it.
Naturally, there can be multiple availability attributes on a
declaration, for different platforms; only the current platform
matters when checking availability attributes.
The only platforms this attribute currently works for are "ios" and
"macosx", since we already have -mxxxx-version-min flags for them and we
have experience there with macro tricks translating down to the
deprecated/unavailable/weak_import attributes. The end goal is to open
this up to other platforms, and even extension to other "platforms"
that are really libraries (say, through a #pragma clang
define_system), but that hasn't yet been designed and we may want to
shake out more issues with this narrower problem first.
Addresses <rdar://problem/6690412>.
As a drive-by bug-fix, if an entity is both deprecated and
unavailable, we only emit the "unavailable" diagnostic.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@128127 91177308-0d34-0410-b5e6-96231b3b80d8
Change the interface to expose the new information and deal with the enormous fallout.
Introduce the new ExceptionSpecificationType value EST_DynamicNone to more easily deal with empty throw specifications.
Update the tests for noexcept and fix the various bugs uncovered, such as lack of tentative parsing support.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127537 91177308-0d34-0410-b5e6-96231b3b80d8
without having to use multiple runs and intermediate files.
Intended for testing & debugging of chained PCH.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127339 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
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
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
source-location information into a NestedNameSpecifierLocBuilder
class, which lives within the AST library and centralize all knowledge
of the format of nested-name-specifier location information here.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126716 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
LabelDecl and LabelStmt. There is a 1-1 correspondence between the
two, but this simplifies a bunch of code by itself. This is because
labels are the only place where we previously had references to random
other statements, causing grief for AST serialization and other stuff.
This does cause one regression (attr(unused) doesn't silence unused
label warnings) which I'll address next.
This does fix some minor bugs:
1. "The only valid attribute " diagnostic was capitalized.
2. Various diagnostics printed as ''labelname'' instead of 'labelname'
3. This reduces duplication of label checking between functions and blocks.
Review appreciated, particularly for the cindex and template bits.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125733 91177308-0d34-0410-b5e6-96231b3b80d8
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
Temporarily set the first (canonical) declaration as the previous one, which is the one that
matters, and mark the real previous DeclID to be loaded & attached later on.
Fixes rdar://8956193.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125434 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
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
overridden via remapping. Thus, when we create a "virtual" file in the
file manager, we still stat() the real file that lives behind it so
that we can provide proper uniquing based on inodes. This helps keep
the file manager much more consistent.
To take advantage of this when reparsing files in libclang, we disable
the use of the stat() cache when reparsing or performing code
completion, since the stat() cache is very likely to be out of date in
this use case.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@124971 91177308-0d34-0410-b5e6-96231b3b80d8
Chandler Carruth
Ted Kremenek
John McCall
Argyrios Kyrtzidis
Sebastian Redl
Douglas Gregor
Richard Smith
Peter Collingbourne
Eli Friedman
Abramo Bagnara
Anders Carlsson
NAKAMURA Takumi
Roman Divacky
Nick Lewycky
Chris Lattner