| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
(e.g. due to a broken template argument) following template parameters.
Fixes rdar://problem/8254267
llvm-svn: 109853
|
|
|
|
| |
llvm-svn: 109396
|
|
|
|
|
|
|
|
| |
purpose of access control. Fixes PR7644.
I can't actually find anything directly justifying this, but it seems obvious.
llvm-svn: 108521
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
allows Sema some limited access to the current scope, which we only
use in one way: when Sema is performing some kind of declaration that
is not directly driven by the parser (e.g., due to template
instantiatio or lazy declaration of a member), we can find the Scope
associated with a DeclContext, if that DeclContext is still in the
process of being parsed.
Use this to make the implicit declaration of special member functions
in a C++ class more "scope-less", rather than using the NULL Scope hack.
llvm-svn: 107491
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is more targeted, as it simply provides toggle actions for the parser to
turn access checking on and off. We then use these to suppress access checking
only while we parse the template-id (included scope specifier) of an explicit
instantiation and explicit specialization of a class template. The
specialization behavior is an extension, as it seems likely a defect that the
standard did not exempt them as it does explicit instantiations.
This allows the very common practice of specializing trait classes to work for
private, internal types. This doesn't address instantiating or specializing
function templates, although those apparently already partially work.
The naming and style for the Action layer isn't my favorite, comments and
suggestions would be appreciated there.
llvm-svn: 106993
|
|
|
|
|
|
|
|
| |
just skip over the body of the class or class template: it's a
semantic disaster that's likely to cause invariants to break. Fixes
part of <rdar://problem/8104754>.
llvm-svn: 106496
|
|
|
|
|
|
|
|
| |
"previous token" location at the end of the class definition. This
eliminates a badly-placed error + Fix-It when the ';' following a
class definition is missing. Fixes <rdar://problem/8066414>.
llvm-svn: 106175
|
|
|
|
|
|
| |
precise. Fixes PR7336.
llvm-svn: 106170
|
|
|
|
|
|
| |
Patch by David Majnemer!
llvm-svn: 105909
|
|
|
|
| |
llvm-svn: 105525
|
|
|
|
|
|
| |
lead to heartache. Fixes <rdar://problem/8044088>.
llvm-svn: 105178
|
|
|
|
|
|
|
| |
give us a decl back. Makes -cc1 -parse-noop handle a substantially larger
amount of the C++ grammar.
llvm-svn: 104940
|
|
|
|
|
|
|
|
|
|
|
| |
1) Suppress diagnostics as soon as we form the code-completion
token, so we don't get any error/warning spew from the early
end-of-file.
2) If we consume a code-completion token when we weren't expecting
one, go into a code-completion recovery path that produces the best
results it can based on the context that the parser is in.
llvm-svn: 104585
|
|
|
|
|
|
| |
Fixes <rdar://problem/7987650>.
llvm-svn: 104376
|
|
|
|
|
|
| |
Fixes PR7153
llvm-svn: 103954
|
|
|
|
| |
llvm-svn: 103767
|
|
|
|
| |
llvm-svn: 102902
|
|
|
|
|
|
|
| |
ActOnClassTemplateSpecialization and being very confused.
Fixes PR6514 (for non-templated-scope friends).
llvm-svn: 101198
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
end of a struct/class/union in C++, from Justin Bogner!
llvm-svn: 99811
|
|
|
|
|
|
| |
Fixes the crash-on-invalid in PR6629.
llvm-svn: 98698
|
|
|
|
|
|
| |
recovery for those that need it.
llvm-svn: 98689
|
|
|
|
| |
llvm-svn: 98436
|
|
|
|
|
|
|
|
|
|
|
| |
for the purposes of parsing default arguments. In effect, we would
re-introduce the parameter with a default argument N times (where N is
the number of parameters preceding the parameter with a default
argument). This showed up when a defaulted parameter of a member
function of a local class shadowed a parameter of the enclosing
function. Fixes PR6383.
llvm-svn: 97534
|
|
|
|
| |
llvm-svn: 97528
|
|
|
|
|
|
|
|
| |
*not* entering the context of the nested-name-specifier. This was
causing us to look into an uninstantiated template that we shouldn't
look into. Fixes PR6376.
llvm-svn: 97524
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
an *almost* always incorrect case. This only does the lookahead
in the insanely unlikely case, so it shouldn't impact performance.
On this testcase:
struct foo {
}
typedef int x;
Before:
t.c:3:9: error: cannot combine with previous 'struct' declaration specifier
typedef int x;
^
After:
t.c:2:2: error: expected ';' after struct
}
^
;
llvm-svn: 97403
|
|
|
|
|
|
| |
returns a StringRef. Use it to simplify some repetitive code.
llvm-svn: 97322
|
|
|
|
|
|
|
|
|
|
| |
propagating error conditions out of the various annotate-me-a-snowflake
routines. Generally (but not universally) removes redundant diagnostics
as well as, you know, not crashing on bad code. On the other hand,
I have just signed myself up to fix fiddly parser errors for the next
week. Again.
llvm-svn: 97221
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
now cope with the destruction of types named as dependent templates,
e.g.,
y->template Y<T>::~Y()
Nominally, we implement C++0x [basic.lookup.qual]p6. However, we don't
follow the letter of the standard here because that would fail to
parse
template<typename T, typename U>
X0<T, U>::~X0() { }
properly. The problem is captured in core issue 339, which gives some
(but not enough!) guidance. I expect to revisit this code when the
resolution of 339 is clear, and/or we start capturing better source
information for DeclarationNames.
Fixes PR6152.
llvm-svn: 96367
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
we would just leak them all over the place, with no clear ownership of
these objects at all. AttributeList objects would get leaked on both
error and non-error paths.
Note: I introduced the usage of llvm::OwningPtr<AttributeList> to
manage these objects, which is particularly useful for methods with
multiple return sites. In at least one method I used them even when
they weren't strictly necessary because it clarified the ownership
semantics and made the code easier to read. Should the excessive
'take()' and 'reset()' calls become a performance issue we can always
re-evaluate.
Note+1: I believe I have not introduced any double-frees, but it would
be nice for someone to review this.
This fixes <rdar://problem/7635046>.
llvm-svn: 95847
|
|
|
|
|
|
| |
from Keir Mierle!
llvm-svn: 95516
|
|
|
|
| |
llvm-svn: 95510
|
|
|
|
|
|
| |
to ParseClassSpecifier, to make its decision easier. Fixes PR6200.
llvm-svn: 95255
|
|
|
|
| |
llvm-svn: 95246
|
|
|
|
| |
llvm-svn: 95185
|
|
|
|
|
|
|
|
|
| |
type qualifiers and type specifiers in any order. For example,
this is valid: struct x {...} typedef y;
This fixes PR6208.
llvm-svn: 95094
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
forgetting a ';' at the end of a struct. For something like:
class c {
}
void foo() {}
we now produce:
t.cc:3:2: error: expected ';' after class
}
^
;
instead of:
t.cc:4:1: error: cannot combine with previous 'class' declaration specifier
void foo() {}
^
t.cc:2:7: error: 'class c' can not be defined in the result type of a function
class c {
^
GCC produces:
t.cc:4: error: new types may not be defined in a return type
t.cc:4: note: (perhaps a semicolon is missing after the definition of ‘c’)
t.cc:4: error: two or more data types in declaration of ‘foo’
I *think* I got the follow set right, but if I forgot anything, we'll start
getting spurious "expected ';' after class" errors, let me know if you see
any.
llvm-svn: 95042
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
t.cc:4:3: error: expected ';' at end of declaration list
int y;
^
t.cc:6:1: error: expected ';' at end of declaration list
};
^
After:
t.cc:3:8: error: expected ';' at end of declaration list
int x
^
;
t.cc:5:8: error: expected ';' at end of declaration list
int z
^
;
llvm-svn: 95039
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(necessarily simultaneous) changes:
- CXXBaseOrMemberInitializer now contains only a single initializer
rather than a set of initialiation arguments + a constructor. The
single initializer covers all aspects of initialization, including
constructor calls as necessary but also cleanup of temporaries
created by the initializer (which we never handled
before!).
- Rework + simplify code generation for CXXBaseOrMemberInitializers,
since we can now just emit the initializer as an initializer.
- Switched base and member initialization over to the new
initialization code (InitializationSequence), so that it
- Improved diagnostics for the new initialization code when
initializing bases and members, to match the diagnostics produced
by the previous (special-purpose) code.
- Simplify the representation of type-checked constructor initializers in
templates; instead of keeping the fully-type-checked AST, which is
rather hard to undo at template instantiation time, throw away the
type-checked AST and store the raw expressions in the AST. This
simplifies instantiation, but loses a little but of information in
the AST.
- When type-checking implicit base or member initializers within a
dependent context, don't add the generated initializers into the
AST, because they'll look like they were explicit.
- Record in CXXConstructExpr when the constructor call is to
initialize a base class, so that CodeGen does not have to infer it
from context. This ensures that we call the right kind of
constructor.
There are also a few "opportunity" fixes here that were needed to not
regress, for example:
- Diagnose default-initialization of a const-qualified class that
does not have a user-declared default constructor. We had this
diagnostic specifically for bases and members, but missed it for
variables. That's fixed now.
- When defining the implicit constructors, destructor, and
copy-assignment operator, set the CurContext to that constructor
when we're defining the body.
llvm-svn: 94952
|
|
|
|
|
|
|
| |
the tag kind (union, struct, class, enum) over to the name of the tag,
if there is a name, since most clients want to point at the name.
llvm-svn: 94424
|
|
|
|
| |
llvm-svn: 94268
|
|
|
|
|
|
|
|
|
|
|
|
| |
distinguish between nested classes (whose member functions cannot be
parsed until the innermost non-nested class is complete) and local
classes (that are defined within a function but are not necessarily
nested). The upshot of this change, which fixes PR5764, is that the
bodies of member functions of local (non-nested) classes need to be
parsed when the local class is complete (and no later), since they may
refer to function-local static variables, typedefs, enums, etc.
llvm-svn: 93653
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
name a template, when they occur in a base-specifier. This is one of
the (few) places where we know for sure that an identifier followed by
a '<' must be a template name, so we can diagnose and recover well:
test/SemaTemplate/dependent-base-classes.cpp:9:16: error: missing
'template'
keyword prior to dependent template name 'T::apply'
struct X1 : T::apply<U> { }; // expected-error{{missing 'template' ...
^
template
test/SemaTemplate/dependent-base-classes.cpp:12:13: error: unknown
template name
'vector'
struct X2 : vector<T> { }; // expected-error{{unknown template name
'vector'}}
^
2 diagnostics generated.
llvm-svn: 93257
|
|
|
|
|
|
|
|
|
| |
initializers. This isn't actually in the C++ grammar (in any version),
but that's clearly an oversight: both GCC and EDG support this syntax,
and it's used within Boost code. I'll file a core issue proposing
precisely the change made here. Fixes PR6008.
llvm-svn: 93243
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because of the rules of base-class lookup* and the restrictions on typedefs, it
was actually impossible for this to cause any problems more serious than the
spurious acceptance of
template <class T> class A : B<A> { ... };
instead of
template <class T> class A : B<A<T> > { ... };
but I'm sure we can all agree that that is a very important restriction which
is well worth making another Parser->Sema call for.
(*) n.b. clang++ does not implement these rules correctly; we are not ignoring
non-type names
llvm-svn: 91792
|
|
|
|
|
|
| |
quite right; I'll come back to it later. It does fix PR 5741.
llvm-svn: 91789
|