| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
preparation for teaching this function how to diagnose a correction that
includes importing a module.
llvm-svn: 188602
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The removal is tried by retrying the failed lookup of a correction
candidate with either the MemberContext or SS (CXXScopeSpecifier) or
both set to NULL if they weren't already. If the candidate identifier
is then looked up successfully, make a note in the candidate that the
SourceRange should include any existing nested name specifier even if
the candidate isn't adding a different one (i.e. the candidate has a
NULL NestedNameSpecifier).
Also tweak the diagnostic messages to differentiate between a suggestion
that just replaces the identifer but leaves the existing nested name
specifier intact and one that replaces the entire qualified identifier,
in cases where the suggested replacement is unqualified.
llvm-svn: 185487
|
|
|
|
| |
llvm-svn: 184379
|
|
|
|
| |
llvm-svn: 177954
|
|
|
|
| |
llvm-svn: 173277
|
|
|
|
| |
llvm-svn: 171367
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
|
|
|
|
|
|
|
|
| |
and defined within the current instantiation, but which are not part of the
current instantiation. Previously, it would look at bases which could be
specialized separately from the current template.
llvm-svn: 168477
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When suggesting "foo::bar" as a correction for "fob::bar" we mistakenly
replaced only "bar" with "foo::bar" producing "fob::foo::bar" which was broken.
This corrects that replacement in as many places as I could find & provides
test cases for all those cases I could find a test case for. There are a couple
that don't seem to be reachable (one looks entirely dead, the other just
doesn't seem to ever get called with a namespace to namespace change).
Review by Richard Smith ( http://llvm-reviews.chandlerc.com/D57 ).
llvm-svn: 165817
|
|
|
|
|
|
|
|
|
|
|
| |
off PartialDiagnostic. PartialDiagnostic is rather heavyweight for
something that is in the critical path and is rarely used. So, switch
over to an abstract-class-based callback mechanism that delays most of
the work until a diagnostic is actually produced. Good for ~11k code
size reduction in the compiler and 1% speedup in -fsyntax-only on the
code in <rdar://problem/11004361>.
llvm-svn: 156176
|
|
|
|
|
|
|
|
|
|
|
| |
[basic.lookup.classref]p1 and p4, which concerns name lookup for
nested-name-specifiers and template names, respectively, in a member
access expression. C++98/03 forces us to look both in the scope of the
object and in the current scope, then compare the results. C++11 just
takes the result from the scope of the object, if something is
found. Fixes <rdar://problem/11328502>.
llvm-svn: 155935
|
|
|
|
|
|
|
| |
class template's definition, and for explicit specializations of such enum
members.
llvm-svn: 153304
|
|
|
|
|
|
|
|
| |
scoped enumeration members. Later uses of an enumeration temploid as a nested
name specifier should cause its instantiation. Plus some groundwork for
explicit specialization of member enumerations of class templates.
llvm-svn: 152750
|
|
|
|
|
|
|
|
|
|
| |
(Lex to AST).
The member variable is always "LangOpts" and the member function is always "getLangOpts".
Reviewed by Chris Lattner
llvm-svn: 152536
|
|
|
|
|
|
|
|
|
|
| |
DependentTemplateSpecializationTypeLoc nodes (DTSTLoc).
The new info is propagated to TSTLoc on template instantiation, getting rid of 3 FIXMEs in TreeTransform.h and another one Parser.cpp.
Simplified code in TypeSpecLocFiller visitor methods for DTSTLoc and DependentNameTypeLoc by removing what now seems to be dead code (adding corresponding assertions).
llvm-svn: 149923
|
|
|
|
|
|
| |
process removed some naming ambiguities.
llvm-svn: 149870
|
|
|
|
| |
llvm-svn: 149451
|
|
|
|
| |
llvm-svn: 149127
|
|
|
|
|
|
| |
appropriate or when GCC requires it)
llvm-svn: 148292
|
|
|
|
|
|
| |
improvng the typo correction results in certain situations.
llvm-svn: 148052
|
|
|
|
| |
llvm-svn: 145785
|
|
|
|
| |
llvm-svn: 142568
|
|
|
|
| |
llvm-svn: 142426
|
|
|
|
|
|
|
| |
for better self-documenting code, since the semantics
are subtly different from getDefinition().
llvm-svn: 141355
|
|
|
|
| |
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
|