| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The parser can only be tricked into parsing a function template
definition by inserting a typename keyword before the function template
declaration. This used to make us crash, and now it's fixed.
While here, remove an unneeded boolean parameter from ParseDeclGroup.
This boolean always corresponded to non-typedef declarators at file
scope. ParseDeclGroup already has precise diagnostics for the function
definition typedef case, so we can let that through.
Fixes PR21839.
llvm-svn: 224287
|
|
|
|
| |
llvm-svn: 218468
|
|
|
|
|
|
| |
declaring a template template parameter.
llvm-svn: 211031
|
|
|
|
|
|
| |
In delayed template parsing mode, adjust the template depth counter for each template parameter list associated with an out of line member template specialization.
llvm-svn: 196351
|
|
|
|
| |
llvm-svn: 194291
|
|
|
|
| |
llvm-svn: 194281
|
|
|
|
|
|
| |
template parameter.
llvm-svn: 184884
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Specifically, using a an integer outside [0, 1] as a boolean constant seems to
be an easy mistake to make with things like "x == a || b" where the author
intended "x == a || x == b".
The bug caused by calling SkipUntil with three token kinds was also identified
by a VC diagnostic & reported by Francois Pichet as review feedback for my
commit r154163. I've included test cases to verify the error recovery that was
broken/poorly implemented due to this bug.
The other fix (lib/Sema/SemaExpr.cpp) seems like that code was never actually
reached in any of Clang's tests & is related to Objective C features I'm not
familiar with, so I've not been able to construct a test case for it. Perhaps
someone else can.
llvm-svn: 154325
|
|
|
|
|
|
|
|
|
|
|
| |
In a few cases clang emitted a rather content-free diagnostic: 'parse error'.
This change replaces two actual cases (template parameter parsing and K&R
parameter declaration parsing) with more specific diagnostics and removes a
third dead case of this in the BalancedDelimiterTracker (the ctor already
checked the invariant necessary to ensure that the diag::parse_error was never
actually used).
llvm-svn: 154224
|
|
|
|
| |
llvm-svn: 154164
|
|
|
|
|
|
|
|
|
|
|
| |
Based on Doug's feedback to r153887 this omits the FixIt if the following token
isn't syntactically valid for the context. (not a comma, '...', identifier,
'>', or '>>')
There's a bunch of work to handle the '>>' case, but it makes for a much more
pleasant diagnostic in this case.
llvm-svn: 154163
|
|
|
|
|
|
|
|
| |
parameter.
Change suggested by Sebastian Redl on review feedback from r153887.
llvm-svn: 154102
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The diagnostic message correctly informs the user that they have omitted the
'class' keyword, but neither suggests this insertion as a fixit, nor attempts
to recover as if they had provided the keyword.
This fixes the recovery, adds the fixit, and adds a separate diagnostic and
corresponding replacement fixit for cases where the user wrote 'struct' or
'typename' instead of 'class' (suggested by Richard Smith as a possible common
mistake).
I'm not sure the diagnostic message for either the original or new cases feel
very Clang-esque, so I'm open to suggestions there. The fixit hints make it
fairly easy to see what's required, though.
llvm-svn: 153887
|
|
|
|
|
|
| |
list, complain about it! Fixes PR7053.
llvm-svn: 116551
|
|
|
|
|
|
|
| |
warning. It's not harmful to have such pointless declarations, and GCC
does not diagnose this issue consistently.
llvm-svn: 100814
|
|
|
|
|
|
|
|
| |
context. This happens fairly rarely (which is why we got away with
this bug). Fixes PR6184, where we skipped over the template parameter
scope while tentatively parsing.
llvm-svn: 95376
|
|
|
|
|
|
|
|
|
| |
- This is designed to make it obvious that %clang_cc1 is a "test variable"
which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
can be useful to redefine what gets run as 'clang -cc1' (for example, to set
a default target).
llvm-svn: 91446
|
|
|
|
|
|
| |
going away).
llvm-svn: 90066
|
|
|
|
| |
llvm-svn: 89874
|
|
|
|
|
|
|
|
| |
template<> struct foo<int> { ... };
where "foo" does not refer to a template. Fixes PR3844.
llvm-svn: 85616
|
|
|
|
| |
llvm-svn: 85236
|
|
|
|
|
|
|
|
|
|
|
| |
templates, and keep track of how those member classes were
instantiated or specialized.
Make sure that we don't try to instantiate an explicitly-specialized
member class of a class template, when that explicit specialization
was a declaration rather than a definition.
llvm-svn: 83547
|
|
|
|
|
|
|
|
| |
member functions of class template specializations, and static data
members. The mechanics are (mostly) present, but the semantic analysis
is very weak.
llvm-svn: 82789
|
|
|
|
| |
llvm-svn: 81346
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
templates, e.g.,
template<typename T>
struct Outer {
struct Inner;
};
template<typename T>
struct Outer<T>::Inner {
// ...
};
Implementing this feature required some extensions to ActOnTag, which
now takes a set of template parameter lists, and is the precursor to
removing the ActOnClassTemplate function from the parser Action
interface. The reason for this approach is simple: the parser cannot
tell the difference between a class template definition and the
definition of a member of a class template; both have template
parameter lists, and semantic analysis determines what that template
parameter list means.
There is still some cleanup to do with ActOnTag and
ActOnClassTemplate. This commit provides the basic functionality we
need, however.
llvm-svn: 76820
|
|
|
|
|
|
|
| |
data members of class templates. We don't instantiate the definitions yet,
however.
llvm-svn: 76756
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
templates.
For example, this now type-checks (but does not instantiate the body
of deref<int>):
template<typename T> T& deref(T* t) { return *t; }
void test(int *ip) {
int &ir = deref(ip);
}
Specific changes/additions:
* Template argument deduction from a call to a function template.
* Instantiation of a function template specializations (just the
declarations) from the template arguments deduced from a call.
* FunctionTemplateDecls are stored directly in declaration contexts
and found via name lookup (all forms), rather than finding the
FunctionDecl and then realizing it is a template. This is
responsible for most of the churn, since some of the core
declaration matching and lookup code assumes that all functions are
FunctionDecls.
llvm-svn: 74213
|
|
|
|
|
|
| |
ActOnFunctionDeclarator for function template definitions
llvm-svn: 74040
|
|
|
|
|
|
|
|
|
|
| |
<rdar://problem/6952203>.
To do this, we actually remove a not-quite-correct optimization in the
C++ name lookup routines. We'll revisit this optimization for the
general case once more C++ is working.
llvm-svn: 73659
|
|
|
|
|
|
|
|
| |
-Makes typeof consistent with sizeof/alignof
-Fixes a bug when '>' is in a typeof expression, inside a template type param:
A<typeof(x>1)> a;
llvm-svn: 72255
|
|
|
|
|
|
|
|
|
|
| |
parse just a single declaration and provide a reasonable diagnostic
when the "only one declarator per template declaration" rule is
violated. This eliminates some ugly, ugly hackery where we used to
require thatn the layout of a DeclGroup of a single element be the
same as the layout of a single declaration.
llvm-svn: 71596
|
|
|
|
|
|
| |
Tests and drivers updated, still need to shuffle dirs.
llvm-svn: 67602
|
|
|
|
|
|
| |
extensions). This caught a couple bugs in our test suite :)
llvm-svn: 64686
|
|
|
|
|
|
|
|
|
| |
arguments. This commit covers checking and merging default template
arguments from previous declarations, but it does not cover the actual
use of default template arguments when naming class template
specializations.
llvm-svn: 64229
|
|
|
|
| |
llvm-svn: 63750
|
|
|
|
|
|
|
|
| |
Examples:
int;
typedef int;
llvm-svn: 61454
|
|
|
|
|
|
| |
actually do anything with the template arguments, but they'll be used to create template declarations
llvm-svn: 61413
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
parameters, with some semantic analysis:
- Template parameters are introduced into template parameter scope
- Complain about template parameter shadowing (except in Microsoft mode)
Note that we leak template parameter declarations like crazy, a
problem we'll remedy once we actually create proper declarations for
templates.
Next up: dependent types and value-dependent/type-dependent
expressions.
llvm-svn: 60597
|
|
|
|
|
|
|
|
|
| |
- Template parameter scope to hold the template parameters
- Template parameter context for parsing declarators
- Actions for template type parameters and non-type template
parameters
llvm-svn: 60387
|
|
llvm-svn: 60384
|