| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Fixes assertion later on. rdar://9122937 & http://llvm.org/PR9459
llvm-svn: 130006
|
| |
|
|
|
|
| |
warnings I introduced lately.
llvm-svn: 129986
|
| |
|
|
| |
llvm-svn: 129567
|
| |
|
|
| |
llvm-svn: 129242
|
| |
|
|
|
|
|
|
| |
of template class. The new value is ignored.
This fixes 1 error when parsing MSVC 2010 header files with clang.
llvm-svn: 129240
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch authored by Eric Niebler.
Many methods on the Sema class (e.g. ConvertPropertyForRValue) take Expr
pointers as in/out parameters (Expr *&). This is especially true for the
routines that apply implicit conversions to nodes in-place. This design is
workable only as long as those conversions cannot fail. If they are allowed
to fail, they need a way to report their failures. The typical way of doing
this in clang is to use an ExprResult, which has an extra bit to signal a
valid/invalid state. Returning ExprResult is de riguour elsewhere in the Sema
interface. We suggest changing the Expr *& parameters in the Sema interface
to ExprResult &. This increases interface consistency and maintainability.
This interface change is important for work supporting MS-style C++
properties. For reasons explained here
<http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-February/013180.html>,
seemingly trivial operations like rvalue/lvalue conversions that formerly
could not fail now can. (The reason is that given the semantics of the
feature, getter/setter method lookup cannot happen until the point of use, at
which point it may be found that the method does not exist, or it may have the
wrong type, or overload resolution may fail, or it may be inaccessible.)
llvm-svn: 129143
|
| |
|
|
|
|
| |
non-header file.
llvm-svn: 128780
|
| |
|
|
| |
llvm-svn: 128401
|
| |
|
|
|
|
| |
functionality changed.
llvm-svn: 128396
|
| |
|
|
|
|
| |
specifications within the global scope, from Elliot Glaysher.
llvm-svn: 128352
|
| |
|
|
| |
llvm-svn: 128280
|
| |
|
|
|
|
| |
parse it though, although that will change shortly.
llvm-svn: 128277
|
| |
|
|
| |
llvm-svn: 128253
|
| |
|
|
| |
llvm-svn: 128188
|
| |
|
|
| |
llvm-svn: 127980
|
| |
|
|
|
|
| |
global using directives in C++ headers, from Elliot Glaysher!
llvm-svn: 127881
|
| |
|
|
| |
llvm-svn: 127876
|
| |
|
|
|
|
|
|
| |
reference-to-void type). Don't crash if it does.
Also fix an issue where type source information for the resulting type was being lost.
llvm-svn: 127811
|
| |
|
|
|
|
| |
noexcept specifiers, unique FunctionProtoTypes with a ContextualFoldingSet, as suggested by John McCall.
llvm-svn: 127568
|
| |
|
|
|
|
| |
It is only meant for the release branch.
llvm-svn: 127544
|
| |
|
|
| |
llvm-svn: 127543
|
| |
|
|
|
|
| |
It is only meant for the release branch.
llvm-svn: 127542
|
| |
|
|
| |
llvm-svn: 127541
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 127536
|
| |
|
|
|
|
|
| |
extending the existing support for sizeof and alignof. Original
patch by Guy Benyei.
llvm-svn: 127475
|
| |
|
|
| |
llvm-svn: 127404
|
| |
|
|
|
|
| |
keywords for Objective-C+ and C++0x.
llvm-svn: 127253
|
| |
|
|
|
|
| |
range for declarations using postfix types.
llvm-svn: 127251
|
| |
|
|
| |
llvm-svn: 127242
|
| |
|
|
| |
llvm-svn: 127225
|
| |
|
|
|
|
| |
ExtProtoInfo.", this time with the missing header.
llvm-svn: 127118
|
| |
|
|
|
|
|
|
| |
ExtProtoInfo."
It seems missing "clang/Basic/ExceptionSpecificationType.h".
llvm-svn: 127115
|
| |
|
|
| |
llvm-svn: 127112
|
| |
|
|
| |
llvm-svn: 126997
|
| |
|
|
|
|
| |
rdar://9083431 & http://llvm.org/PR9396.
llvm-svn: 126966
|
| |
|
|
| |
llvm-svn: 126945
|
| |
|
|
| |
llvm-svn: 126943
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
location information for elaborated types. *sigh*
llvm-svn: 126753
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
buildbot breakage.
llvm-svn: 126746
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
source-location information. We don't actually preserve this
information in any of the resulting TypeLocs (yet), so it doesn't
matter.
llvm-svn: 126693
|
| |
|
|
|
|
| |
MemberExpr, the last of the expressions with qualifiers!
llvm-svn: 126688
|
| |
|
|
|
|
|
|
|
|
|
| |
This successfully performs constructor lookup and verifies that a
delegating initializer is the only initializer present.
This does not perform loop detection in the initialization, but it also
doesn't codegen delegating constructors at all, so this won't cause
runtime infinite loops yet.
llvm-svn: 126552
|
| |
|
|
|
|
| |
aliases.
llvm-svn: 126496
|
| |
|
|
| |
llvm-svn: 126489
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|