| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 140407
|
|
|
|
| |
llvm-svn: 140367
|
|
|
|
|
|
|
|
| |
that this flag must be used only for Microsoft extensions and not emulation; to avoid confusion with the new LangOptions::MicrosoftMode flag.
Many of the code now under LangOptions::MicrosoftExt will eventually be moved under the LangOptions::MicrosoftMode flag.
llvm-svn: 139987
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
resolve Identifier during BuildCXXNestedNameSpecifier, then extend the SS with Identifier. This will have the effect of resolving Identifier during template instantiation. The goal is to be able to resolve a function call whose nested-name-specifier is located inside a dependent base class.
class C {
public:
static void foo2() { }
};
template <class T> class A {
public:
typedef C D;
};
template <class T> class B : public A<T> {
public:
void foo() { D::foo2(); }
};
Note that this won't work if the NestedNameSpecifier refers to a type.
This fixes 1 error when parsing the MSVC 2010 standard headers file with clang.
llvm-svn: 136203
|
|
|
|
|
|
|
| |
as scope specifiers; diagnose the attempt, rather than letting it go
to an assert. The rest of PR10264.
llvm-svn: 134479
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vector<int>
to
std::vector<int>
Patch by Kaelyn Uhrain, with minor tweaks + PCH support from me. Fixes
PR5776/<rdar://problem/8652971>.
Thanks Kaelyn!
llvm-svn: 134007
|
|
|
|
|
|
|
|
|
| |
nested-name-specifier, re-evaluate the nested-name-specifier as if we
were entering that context (which we did!), so that we'll resolve a
template-id to a particular class template partial
specialization. Fixes PR9913.
llvm-svn: 131383
|
|
|
|
| |
llvm-svn: 130953
|
|
|
|
|
|
|
|
| |
information. Rather than looking at the declaration kind to figure out
what TypeLoc to build, look at the type; it makes so much more
sense. Fixes <rdar://problem/9086649>.
llvm-svn: 130882
|
|
|
|
| |
llvm-svn: 129567
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 127037
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 126593
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 126391
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 126346
|
|
|
|
|
|
|
|
|
|
|
| |
current instantiation, even though we have a RecordDecl describing
them. Fixes PR9255.
Amusingly, I've had this patch sitting around for a month or two
because it was "obviously" wrong, but hadn't gotten around to writing
a test case to submit the fix :)
llvm-svn: 126038
|
|
|
|
|
|
| |
thousand other things which were (generally inadvertantly) relying on that.
llvm-svn: 123814
|
|
|
|
|
|
| |
semantics slightly. No functionality change in the absence of inline namespaces. Also, change a few places where inline namespaces actually make a difference to be prepared for them.
llvm-svn: 112563
|
|
|
|
|
|
|
| |
Clients of Sema don't need to know (for example) the list of diagnostics we
support.
llvm-svn: 112093
|
|
|
|
| |
llvm-svn: 111901
|
|
|
|
|
|
|
|
|
| |
- move DeclSpec &c into the Sema library
- move ParseAST into the Parse library
Reflect this change in a thousand different includes.
Reflect this change in the link orders.
llvm-svn: 111667
|
|
|
|
| |
llvm-svn: 110945
|
|
|
|
|
|
|
|
| |
dependent bases, construct a dependent nested-name-specifier rather
than complaining that the name could not be found within the current
instantiation itself. Fixes PR7725.
llvm-svn: 109582
|
|
|
|
|
|
|
| |
a template, be sure to include the template arguments from the
injected-class-name. Fixes PR7587.
llvm-svn: 107895
|
|
|
|
|
|
|
| |
looking for, reset the name within the LookupResult structure in
addition to clearing out the results. Fixes PR7508.
llvm-svn: 107197
|
|
|
|
|
|
|
| |
already knows what context it's looking in. Just pass that context in
instead of (questionably) recalculating it.
llvm-svn: 102818
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of a class template or class template partial specialization. That is to
say, in
template <class T> class A { ... };
or
template <class T> class B<const T*> { ... };
make 'A<T>' and 'B<const T*>' sugar for the corresponding InjectedClassNameType
when written inside the appropriate context. This allows us to track the
current instantiation appropriately even inside AST routines. It also allows
us to compute a DeclContext for a type much more efficiently, at some extra
cost every time we write a template specialization (which can be optimized,
but I've left it simple in this patch).
llvm-svn: 102407
|
|
|
|
|
|
|
|
| |
when they are not complete (since we could not match them up to
anything) and ensuring that enum parsing can cope with dependent
elaborated-type-specifiers. Fixes PR6915 and PR6649.
llvm-svn: 102247
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
generally recover from typos in keywords (since we would effectively
have to mangle the token stream). However, there are still benefits to
typo-correcting with keywords:
- We don't make stupid suggestions when the user typed something
that is similar to a keyword.
- We can suggest the keyword in a diagnostic (did you mean
"static_cast"?), even if we can't recover and therefore don't have
a fix-it.
llvm-svn: 101274
|
|
|
|
|
|
|
| |
Declarator that depends on it. This fixes several redundant errors and bad
recoveries.
llvm-svn: 100779
|
|
|
|
|
|
| |
the C-only "optimization".
llvm-svn: 100022
|
|
|
|
| |
llvm-svn: 100018
|
|
|
|
|
|
|
| |
term "fix-it" everywhere and even *I* get tired of long names
sometimes. No functionality change.
llvm-svn: 100008
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
injected class name of a class template or class template partial specialization.
This is a non-canonical type; the canonical type is still a template
specialization type. This becomes the TypeForDecl of the pattern declaration,
which cleans up some amount of code (and complicates some other parts, but
whatever).
Fixes PR6326 and probably a few others, primarily by re-establishing a few
invariants about TypeLoc sizes.
llvm-svn: 98134
|
|
|
|
|
|
|
|
|
| |
class types, dependent types, and namespaces. I had previously
weakened this invariant while working on parsing pseudo-destructor
expressions, but recent work in that area has made these changes
unnecessary.
llvm-svn: 97112
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pseudo-destructor expressions, and builds the CXXPseudoDestructorExpr
node directly. Currently, this only affects pseudo-destructor
expressions when they are parsed, but not after template
instantiation. That's coming next...
Improve parsing of pseudo-destructor-names. When parsing the
nested-name-specifier and we hit the sequence of tokens X :: ~, query
the actual module to determine whether X is a type-name (in which case
the X :: is part of the pseudo-destructor-name but not the
nested-name-specifier) or not (in which case the X :: is part of the
nested-name-specifier).
llvm-svn: 97058
|
|
|
|
|
|
|
|
|
|
|
|
| |
nested-name-specifier, e.g.,
typedef int Int;
int *p;
p->Int::~Int();
This weakens the invariant that the only types in nested-name-specifiers are tag types (restricted to class types in C++98/03). However, we weaken this invariant as little as possible, accepting arbitrary types in nested-name-specifiers only when we're in a member access expression that looks like a pseudo-destructor expression.
llvm-svn: 96743
|
|
|
|
|
|
| |
dependent DeclContext to be "complete". Fixes PR6236.
llvm-svn: 95359
|
|
|
|
|
|
|
|
| |
in a member access expression referring into the current instantiation
need not be resolved at template definition *if* the current
instantiation has any dependent base classes. Fixes PR6081.
llvm-svn: 93877
|
|
|
|
|
|
| |
qualifiers. Fixes PR6021.
llvm-svn: 93513
|
|
|
|
|
|
|
|
| |
finds nothing), and the current instantiation has dependent base
classes, treat the qualified lookup as if it referred to an unknown
specialization. Fixes PR6031.
llvm-svn: 93433
|
|
|
|
|
|
|
| |
pointing to the declaration that we found that has that name (if it is
unique).
llvm-svn: 92877
|
|
|
|
|
|
|
|
|
|
| |
typo.cpp:18:1: error: use of undeclared identifier 'other_std'; did
you mean 'otherstd'?
other_std::strng str1;
^~~~~~~~~
otherstd
llvm-svn: 92350
|
|
|
|
| |
llvm-svn: 92307
|
|
|
|
|
|
|
| |
the redeclaration problems in the [temp.explicit]p3 testcase worse, but I can
live with that; they'll need to be fixed more holistically anyhow.
llvm-svn: 91771
|
|
|
|
|
|
|
| |
in a file context. In well-formed code, only happens with friend functions.
Fixes PR 5760.
llvm-svn: 91146
|
|
|
|
|
|
| |
This time with a fix to bail out when in a dependent context.
llvm-svn: 90730
|
|
|
|
|
|
| |
to fix it ATM.
llvm-svn: 90717
|