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
headers, which use C++0x generalized initializer lists. Per PR7069, it
appears that the only use is as the return type of a function, so this
commit enables this extension just in that narrow case. If it's enough
for libstdc++ 4.5, or if it can be trivially extended to work with
libstdc++ 4.5, we'll keep it. Otherwise, or if this breaks anything,
we'll revert and wait for the real feature.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127507 91177308-0d34-0410-b5e6-96231b3b80d8
to cope with non-type templates by providing appropriate
errors. Previously, we would either assert, crash, or silently build a
dependent type when we shouldn't. Fixes PR9226.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127037 91177308-0d34-0410-b5e6-96231b3b80d8
template specialization types. This also required some parser tweaks,
since we were losing track of the nested-name-specifier's source
location information in several places in the parser. Other notable
changes this required:
- Sema::ActOnTagTemplateIdType now type-checks and forms the
appropriate type nodes (+ source-location information) for an
elaborated-type-specifier ending in a template-id. Previously, we
used a combination of ActOnTemplateIdType and
ActOnTagTemplateIdType that resulted in an ElaboratedType wrapped
around a DependentTemplateSpecializationType, which duplicated the
keyword ("class", "struct", etc.) and nested-name-specifier
storage.
- Sema::ActOnTemplateIdType now gets a nested-name-specifier, which
it places into the returned type-source location information.
- Sema::ActOnDependentTag now creates types with source-location
information.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126808 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
The previous name was inaccurate as this token in fact appears at
the end of every preprocessing directive, not just macro definitions.
No functionality change, except for a diagnostic tweak.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126631 91177308-0d34-0410-b5e6-96231b3b80d8
nested-name-specifier, e.g.,
T::template apply<U>::
represent the dependent template name specialization as a
DependentTemplateSpecializationType, rather than a
TemplateSpecializationType with a dependent TemplateName.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126593 91177308-0d34-0410-b5e6-96231b3b80d8
specifiers such as
typename T::template apply<U>
Previously, we would turn T::template apply<U> into a
TemplateSpecializationType. Then, we'd reprocess that
TemplateSpecializationType and turn it into either a
TemplateSpecializationType wrapped in an ElaboratedType (when we could
resolve "apply" to a template declaration) or a
DependentTemplateSpecializationType. We now produce the same ASTs but
without generating the intermediate TemplateSpecializationType.
The end goal here is to avoid generating TemplateSpecializationTypes
with dependent template-names, ever. We're not there yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126589 91177308-0d34-0410-b5e6-96231b3b80d8
nested-name-specifiers throughout the parser, and provide a new class
(NestedNameSpecifierLoc) that contains a nested-name-specifier along
with its type-source information.
Right now, this information is completely useless, because we don't
actually store the source-location information anywhere in the
AST. Call this Step 1/N.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126391 91177308-0d34-0410-b5e6-96231b3b80d8
with another component in the nested-name-specifiers, updating its
representation (a NestedNameSpecifier) and source-location information
(currently a SourceRange) simultaneously. This is groundwork for
adding source-location information to nested-name-specifiers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126346 91177308-0d34-0410-b5e6-96231b3b80d8
several ways. We now warn for more of the return types, and correctly
locate the ignored ones. Also adds fix-it hints to remove the ignored
qualifiers. Fixes much of PR9058, although not all of it.
Patch by Hans Wennborg, a couple of minor style tweaks from me.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126321 91177308-0d34-0410-b5e6-96231b3b80d8
enum X : long { Value = 0x100000000 };
when in Microsoft-extension mode (-fms-extensions). This (now C++0x)
feature has been supported since Microsoft Visual Studio .NET 2003.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126243 91177308-0d34-0410-b5e6-96231b3b80d8
* Flag indicating 'we're parsing this auto typed variable's initializer' moved from VarDecl to Sema
* Temporary template parameter list for auto deduction is now allocated on the stack.
* Deduced 'auto' types are now uniqued.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126139 91177308-0d34-0410-b5e6-96231b3b80d8
bugs from other clients that don't expect to see a LabelDecl in a DeclStmt,
but if so they should be easy to fix.
This implements most of PR3429 and rdar://8287027
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125817 91177308-0d34-0410-b5e6-96231b3b80d8
separately handle the case of a local declaration-specifier list,
including all types in the set of options. Fixes
<rdar://problem/8790735> and <rdar://problem/8662831>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125594 91177308-0d34-0410-b5e6-96231b3b80d8
by the code completion token, treat this as a class message send where
the opening square bracket is missing. Fixes <rdar://problem/6970911>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125587 91177308-0d34-0410-b5e6-96231b3b80d8
access-control diagnostics which arise from the portion of the declarator
following the scope specifier, just in case access is granted by
friending the individual method. This can also happen with in-line
member function declarations of class templates due to templated-scope
friend declarations.
We were really playing fast-and-loose before with this sort of thing,
and it turned out to work because *most* friend functions are in file
scope. Making us delay regardless of context exposed several bugs with
how we were manipulating delay. I ended up needing a concept of a
context that's independent of the declarations in which it appears,
and then I actually had to make some things save contexts correctly,
but delay should be much cleaner now.
I also encapsulated all the delayed-diagnostics machinery in a single
subobject of Sema; this is a pattern we might want to consider rolling
out to other components of Sema.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125485 91177308-0d34-0410-b5e6-96231b3b80d8
Fariborz Jahanian
Sebastian Redl
Abramo Bagnara
Douglas Gregor
Peter Collingbourne
Chandler Carruth
Richard Smith
Chris Lattner
John McCall
NAKAMURA Takumi