Commit Graph

142 Commits

Author SHA1 Message Date
John McCall 319963434c Basic, untested implementation for an "unknown any" type requested by LLDB.
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.

llvm-svn: 129065
2011-04-07 08:22:57 +00:00
Douglas Gregor 20b2ebd785 Implement a new 'availability' attribute, that allows one to specify
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.

llvm-svn: 128127
2011-03-23 00:50:03 +00:00
Sebastian Redl fa453cfdc3 Propagate the new exception information to FunctionProtoType.
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.

llvm-svn: 127537
2011-03-12 11:50:43 +00:00
Abramo Bagnara f2a79d94e4 Forgotten part of previous commit.
llvm-svn: 127536
2011-03-12 11:17:06 +00:00
Argyrios Kyrtzidis 35dcda7922 Introduce '-chain-include' option to specify headers that will be converted to chained PCHs in memory
without having to use multiple runs and intermediate files.

Intended for testing & debugging of chained PCH.

llvm-svn: 127339
2011-03-09 17:21:42 +00:00
Anders Carlsson 1f13bb5f00 When deserializing CXXBaseSpecifiers (and offsets), make sure to walk the chain in the correct order.
llvm-svn: 127315
2011-03-09 05:09:32 +00:00
Sebastian Redl 7c6c9e971c Reinstate r127112, "Propagate new-style exception spec information to ExtProtoInfo.", this time with the missing header.
llvm-svn: 127118
2011-03-06 10:52:04 +00:00
NAKAMURA Takumi c92335a87c Revert r127112, "Propagate new-style exception spec information to ExtProtoInfo."
It seems missing "clang/Basic/ExceptionSpecificationType.h".

llvm-svn: 127115
2011-03-06 00:17:36 +00:00
Sebastian Redl 69d37125a9 Propagate new-style exception spec information to ExtProtoInfo.
llvm-svn: 127112
2011-03-05 22:42:26 +00:00
Abramo Bagnara 5093578471 Improved MemberPointerType source locations.
llvm-svn: 127085
2011-03-05 14:42:21 +00:00
Douglas Gregor 9d80212115 Push nested-name-specifier source location information into template
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.

llvm-svn: 126844
2011-03-02 17:09:35 +00:00
Douglas Gregor a7a795bed1 Push nested-name-specifier source-location information into dependent
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.

llvm-svn: 126776
2011-03-01 20:11:18 +00:00
Douglas Gregor 844cb50266 Reinstate the introduction of source-location information for
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.
  

llvm-svn: 126765
2011-03-01 18:12:44 +00:00
Roman Divacky 65b88cdb3b Implement -mrtd which sets the StdCall calling convention to be the default
one.

llvm-svn: 126756
2011-03-01 17:40:53 +00:00
Roman Divacky dc1f68d0a5 Add missing options.
llvm-svn: 126755
2011-03-01 17:36:40 +00:00
Douglas Gregor b3a58b08e0 Revert r126748, my second attempt at nested-name-specifier source
location information for elaborated types. *sigh*

llvm-svn: 126753
2011-03-01 17:25:47 +00:00
Douglas Gregor bf5fe47b12 Reinstate r126737, extending the generation of type-source location
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.

llvm-svn: 126748
2011-03-01 16:31:39 +00:00
Douglas Gregor 62a60c50f4 Revert r126737, the most recent nested-name-specifier location change, for buildbot breakage.
llvm-svn: 126746
2011-03-01 15:34:37 +00:00
Douglas Gregor 9720642c68 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.

llvm-svn: 126737
2011-03-01 03:11:17 +00:00
Douglas Gregor 3d0da5f5dd Push nested-name-specifier source location information into
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.

llvm-svn: 126729
2011-03-01 01:34:45 +00:00
Douglas Gregor 9b27251e58 Refactor the construction of nested-name-specifiers with
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.

llvm-svn: 126716
2011-02-28 23:58:31 +00:00
Douglas Gregor 144548072d Use NestedNameSpecifierLoc within out-of-line variables, function, and
tag definitions. Also, add support for template instantiation of
NestedNameSpecifierLocs.

llvm-svn: 126470
2011-02-25 02:25:35 +00:00
Douglas Gregor a9d87bc6ac Update UsingDecl, UnresolvedUsingTypenameDecl, and
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)

llvm-svn: 126459
2011-02-25 00:36:19 +00:00
Douglas Gregor 7b26ff912f Teach NestedNameSpecifier to keep track of namespace aliases the same
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.

llvm-svn: 126358
2011-02-24 02:36:08 +00:00
Nick Lewycky 3607989847 Preserve what the user passed to -include when emitting .d files. Fixes PR8974!
llvm-svn: 126334
2011-02-23 21:16:44 +00:00
Anders Carlsson 6bbd268396 Add a CXXExceptions flag to LangOptions.
llvm-svn: 126299
2011-02-23 03:04:54 +00:00
Richard Smith 30482bc786 Implement the C++0x deduced 'auto' feature.
This fixes PR 8738, 9060 and 9132.

llvm-svn: 126069
2011-02-20 03:19:35 +00:00
Anders Carlsson ce8dd3a5d4 Add a new ObjCExceptions member variable to LangOptions. This controls whether Objective-C exceptions are enabled or not (they are by default).
llvm-svn: 126061
2011-02-19 23:53:54 +00:00
Chris Lattner c8e630e4db Step #1/N of implementing support for __label__: split labels into
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.

llvm-svn: 125733
2011-02-17 07:39:24 +00:00
Peter Collingbourne 5df20e02af Serialization/deserialization support for floating point #pragma
options, enabled OpenCL extensions and default FP_CONTRACT setting.

llvm-svn: 125589
2011-02-15 19:46:30 +00:00
Argyrios Kyrtzidis 10b2368e9f Allow resolving headers from a PCH even after headers+PCH were moved to 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.

llvm-svn: 125576
2011-02-15 17:54:22 +00:00
Argyrios Kyrtzidis 9fdd25492c When reading the AST, delay loading of the redeclaration chain to avoid deeply nested calls.
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.

llvm-svn: 125434
2011-02-12 07:50:47 +00:00
Douglas Gregor 46c50012ca Rename the operation that loads a preprocessed entity from a given offset to indicate that we're loading from an offset, not an index, lest one be confused. No functionality change.
llvm-svn: 125394
2011-02-11 19:46:30 +00:00
Douglas Gregor 09b6989ef0 Implement two related optimizations that make de-serialization of
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.

llvm-svn: 125286
2011-02-10 17:09:37 +00:00
Peter Collingbourne 9e2c81f00a AST, Sema, Serialization: keep track of cudaConfigureCall
llvm-svn: 125216
2011-02-09 21:04:32 +00:00
Douglas Gregor 92a96f5c32 Split the serialized representation for the detailed preprocessing
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.

llvm-svn: 125117
2011-02-08 21:58:10 +00:00
Douglas Gregor 606c4ac325 Improve our uniquing of file entries when files are re-saved or are
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.

llvm-svn: 124971
2011-02-05 19:42:43 +00:00
Sebastian Redl 0890502f44 Basic implementation of inherited constructors. Only generates declarations, and probably only works for very basic use cases.
llvm-svn: 124970
2011-02-05 19:23:19 +00:00
Douglas Gregor 1732850158 Fix a thinko where I didn't update a consistency check for
PackExpansionType in the AST reader. We need more testing for variadic
templates + PCH, but this fixes PR9073.

llvm-svn: 124662
2011-02-01 15:24:58 +00:00
Douglas Gregor dbe3927026 Basic support for -mms-bitfields, from Carl Norum!
llvm-svn: 124661
2011-02-01 15:15:22 +00:00
Axel Naumann 63fbaeda29 TextDiagnosticPrinter.cpp: Show diagnostics as far as possible even with invalid PresomedLoc, instead of just silencing it.
FileManager.cpp: Allow virtual files in nonexistent directories.
FileManager.cpp: Close FileDescriptor for virtual files that correspond to actual files.
FileManager.cpp: Enable virtual files to be created even for files that were flagged as NON_EXISTENT_FILE, e.g. by a prior (unsuccessful) addFile().

ASTReader.cpp: Read a PCH even if the original source files cannot be found.

Add a test for reading a PCH of a file that has been removed and diagnostics referencing that file.

llvm-svn: 124374
2011-01-27 10:55:51 +00:00
Douglas Gregor db9d664244 Rvalue references for *this:
- 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.

llvm-svn: 124281
2011-01-26 05:01:58 +00:00
John McCall 424cec97bd Change QualType::getTypePtr() to return a const pointer, then change a
thousand other things which were (generally inadvertantly) relying on that.

llvm-svn: 123814
2011-01-19 06:33:43 +00:00
Douglas Gregor 5590be0491 Introduce a new kind of TemplateName that captures a substituted
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.

llvm-svn: 123521
2011-01-15 06:45:20 +00:00
Argyrios Kyrtzidis a88942ad9c Store/retrieve -fshort-enums for PCH, fixes rdar://8854933.
llvm-svn: 123510
2011-01-15 02:56:16 +00:00
Douglas Gregor e1d60df0fc Teach template template argument pack expansions to keep track of the
number of expansions, when we know it, and propagate that information
through Sema.

llvm-svn: 123493
2011-01-14 23:41:42 +00:00
Argyrios Kyrtzidis 243aedb6ec Properly propagate #pragma diagnostic mappings from PCH but not command-line warning flags.
Addresses rdar://8435969&8852495

llvm-svn: 123462
2011-01-14 20:54:07 +00:00
Douglas Gregor 0dca5fdb4e Keep track of the number of expansions to be produced from a type pack
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.

llvm-svn: 123448
2011-01-14 17:04:44 +00:00
Douglas Gregor ada4b79947 Start implementing support for substitution into pack expansions that
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.

llvm-svn: 123425
2011-01-14 02:55:32 +00:00
Alexis Hunt 1d7926502f Renamed CXXBaseOrMemberInitializer to CXXCtorInitializer. This is both shorter,
more accurate, and makes it make sense for it to hold a delegating constructor
call.

llvm-svn: 123084
2011-01-08 20:30:50 +00:00