| Age | Commit message (Collapse) | Author |
|---|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154325 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154224 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154164 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154163 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
parameter.
Change suggested by Sebastian Redl on review feedback from r153887.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154102 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153887 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
list, complain about it! Fixes PR7053.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@116551 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
warning. It's not harmful to have such pointless declarations, and GCC
does not diagnose this issue consistently.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100814 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@95376 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- 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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91446 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
going away).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@90066 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89874 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
template<> struct foo<int> { ... };
where "foo" does not refer to a template. Fixes PR3844.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85616 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85236 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83547 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
member functions of class template specializations, and static data
members. The mechanics are (mostly) present, but the semantic analysis
is very weak.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82789 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@81346 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@76820 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
data members of class templates. We don't instantiate the definitions yet,
however.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@76756 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@74213 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
ActOnFunctionDeclarator for function template definitions
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@74040 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
<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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@73659 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
-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;
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72255 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71596 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Tests and drivers updated, still need to shuffle dirs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67602 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
extensions). This caught a couple bugs in our test suite :)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64686 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64229 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@63750 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Examples:
int;
typedef int;
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@61454 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
actually do anything with the template arguments, but they'll be used to create template declarations
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@61413 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@60597 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- Template parameter scope to hold the template parameters
- Template parameter context for parsing declarators
- Actions for template type parameters and non-type template
parameters
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@60387 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@60384 91177308-0d34-0410-b5e6-96231b3b80d8
|
