Commit Graph

16 Commits

Author SHA1 Message Date
Douglas Gregor f19ac0ede9 Downgrade the "declaration does not declare anything" error to a
warning. It's not harmful to have such pointless declarations, and GCC
does not diagnose this issue consistently.

llvm-svn: 100814
2010-04-08 21:33:23 +00:00
Chris Lattner fd48afe412 Implement PR6423 by using one token of lookahead to disambiguate
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
2010-02-28 18:18:36 +00:00
Chris Lattner afe6a840d4 the declspec of a declaration can have storage-class specifiers,
type qualifiers and type specifiers in any order.   For example,
this is valid: struct x {...} typedef y;

This fixes PR6208.

llvm-svn: 95094
2010-02-02 17:32:27 +00:00
Chris Lattner cf25141d14 Implement PR6180, substantially improving the diagnostics we get from
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
2010-02-02 01:23:29 +00:00
Douglas Gregor bb91767b82 Tighten up the "cannot return array or function type" diagnostic to
say either "array type" or "function type", whichever it is. No reason
to make the user guess.

llvm-svn: 93164
2010-01-11 18:46:21 +00:00
Nuno Lopes e9823fab83 implement PR3962: diagnose more faulty cases of usage of the restrict qualifier. this also removes a FIXME
llvm-svn: 91601
2009-12-17 11:35:26 +00:00
Daniel Dunbar 8fbe78f6fc Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'.
- 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
2009-12-15 20:14:24 +00:00
Daniel Dunbar a45cf5b6b0 Rename clang to clang-cc.
Tests and drivers updated, still need to shuffle dirs.

llvm-svn: 67602
2009-03-24 02:24:46 +00:00
Chris Lattner 810d330cd3 Fix a long standard problem with clang retaining "too much" sugar
information about types.  We often print diagnostics where we say 
"foo_t" is bad, but the user doesn't know how foo_t is declared 
(because it is a typedef).  Fix this by expanding sugar when present
in a diagnostic (and not one of a few special cases, like vectors).

Before:
t.m:5:2: error: invalid operands to binary expression ('typeof(P)' and 'typeof(F)')
 MAX(P, F);
 ^~~~~~~~~
t.m:1:78: note: instantiated from:
#define MAX(A,B)    ({ __typeof__(A) __a = (A); __typeof__(B) __b = (B); __a < __b ? __b : __a; })
                                                                             ^

After:
t.m:5:2: error: invalid operands to binary expression ('typeof(P)' (aka 'struct mystruct') and 'typeof(F)' (aka 'float'))
 MAX(P, F);
 ^~~~~~~~~
t.m:1:78: note: instantiated from:
#define MAX(A,B)    ({ __typeof__(A) __a = (A); __typeof__(B) __b = (B); __a < __b ? __b : __a; })
                                                                             ^

llvm-svn: 65081
2009-02-19 23:45:49 +00:00
Chris Lattner 1e5665e6be Change a whole lot of diagnostics to take QualType's directly
instead of converting them to strings first.  This also fixes a
bunch of minor inconsistencies in the diagnostics emitted by clang
and adds a bunch of FIXME's to DiagnosticKinds.def.

llvm-svn: 59948
2008-11-24 06:25:27 +00:00
Chris Lattner 6f6d226f63 improve error to be something end users will actually understand :)
llvm-svn: 49097
2008-04-02 17:15:17 +00:00
Chris Lattner daaa8ba77e 1) Enforce C99 6.7.3p2: "Types other than pointer types derived from
object or incomplete types shall not be restrict-qualified."

2) Warn about qualifiers on function types: C99 6.7.3p8: "If the 
specification of a function type includes any type qualifiers, the 
behavior is undefined."

3) Implement restrict on C++ references.

4) fix some locations for various C++ reference diagnostics.

llvm-svn: 49081
2008-04-02 06:50:17 +00:00
Steve Naroff f631997cb5 A much better fix for http://llvm.org/bugs/show_bug.cgi?id=1987.
llvm-svn: 47103
2008-02-14 02:58:32 +00:00
Steve Naroff ab468cb14b Allow the parser to detect invalid DeclSpec's. This fixes http://llvm.org/bugs/show_bug.cgi?id=1987.
This commit only "guards" the call to ParseDeclarationSpecifiers() in ParseDeclarationOrFunctionDefinition(). 

We could consider guarding all calls, however this is a bit radical (since it effectively stops parsing the declaration once we have a bad declspec). Will discuss with Chris tomorrow.

llvm-svn: 46984
2008-02-12 04:08:59 +00:00
Steve Naroff 1aa1941889 Declarator::clear(): Null out variable after it's been deleted.
This avoids a double free (which is good:-)

Bug submitted by Eli.

llvm-svn: 46105
2008-01-17 00:36:28 +00:00
Chris Lattner ea72f449fe Implement C99 6.7.5.3p1
llvm-svn: 45188
2007-12-19 05:31:29 +00:00