| 651f13cea278ec967336033dd032faef0e9fc2ec |
|
24-Apr-2014 |
Stephen Hines <srhines@google.com> |
Updated to Clang 3.5a.
Change-Id: I8127eb568f674c2e72635b639a3295381fe8af82
/external/clang/test/Parser/declarators.c
|
| 122e601886ae527d6e7100c589339c05190a168a |
|
08-Jun-2013 |
Serge Pavlov <sepavloff@gmail.com> |
Recognition of empty structures and unions is moved to semantic stage
Differential Revision: http://llvm-reviews.chandlerc.com/D586
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183609 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Parser/declarators.c
|
| 139be7007eba3bd491ca50297888be507753a95d |
|
02-Jul-2012 |
Richard Smith <richard-llvm@metafoo.co.uk> |
A ':' after an enum-specifier at class scope is a bitfield, not a typo for a ';'.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159549 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Parser/declarators.c
|
| 8bb21d32e9ccc9d9c221506dff26acafa8724cca |
|
28-Apr-2012 |
Chris Lattner <sabre@nondot.org> |
switch some uses of ExpectAndConsume(tok::semi to use ExpectAndConsumeSemi. This allows
us to improve this diagnostic (telling us to insert another ")":
t.c:2:19: error: expected ';' at end of declaration
int x = 4+(5-12));
^
;
to:
t.c:2:19: error: extraneous ')' before ';'
int x = 4+(5-12));
^
...telling us to remove the ")". This is PR12595. There are more uses of ExpectAndConsumeSemi
that could be switched over, but I don't hit them on a daily basis :)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155759 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Parser/declarators.c
|
| b031eab1c07fa2c5bd74c7e92f7c938bf3304729 |
|
07-Apr-2012 |
David Blaikie <dblaikie@gmail.com> |
Remove "parse error" in favor of more descriptive diagnostics.
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
/external/clang/test/Parser/declarators.c
|
| cebc3769077bb22003dc47bd22868d0b4c6ce106 |
|
26-Aug-2010 |
John McCall <rjmccall@apple.com> |
...I forgot to check my new test after adding it, and lo, there's slightly different
behavior in C than in C++ (which is what the original test case was).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112199 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Parser/declarators.c
|
| 9e46b8cfb3e6c6feab5664744f52f06a40f9566b |
|
26-Aug-2010 |
John McCall <rjmccall@apple.com> |
Make sure we clear TypeSpecOwned when setting TypeSpecType to something when
it might previously have been a tag TST.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112196 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Parser/declarators.c
|
| 9b3215d5aba6c687a3ee46b0f36367f416ac34cc |
|
12-Jul-2010 |
Chris Lattner <sabre@nondot.org> |
change the 'invalid token after top level declarator' message to be
'expected ';' after top level declarator' which is much less vague.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@108106 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Parser/declarators.c
|
| 004659a56916f2f81ede507c12516c146d6c0df3 |
|
12-Jul-2010 |
Chris Lattner <sabre@nondot.org> |
Fix PR7617 by not entering ParseFunctionDefinition when
a function prototype is followed by a declarator if we
aren't parsing a K&R style identifier list.
Also, avoid skipping randomly after a declaration if a
semicolon is missing. Before we'd get:
t.c:3:1: error: expected function body after function declarator
void bar();
^
Now we get:
t.c:1:11: error: invalid token after top level declarator
void foo()
^
;
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@108105 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Parser/declarators.c
|
| 5ee3734c0b5222a7c445591a1f14102c1b3a289b |
|
31-May-2010 |
Douglas Gregor <dgregor@apple.com> |
Don't try to parse class template specializations in C. It can only
lead to heartache. Fixes <rdar://problem/8044088>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@105178 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Parser/declarators.c
|
| d4eea8362605807327735727a9098abe1eb23b19 |
|
09-Apr-2010 |
Douglas Gregor <dgregor@apple.com> |
Improve diagnostics when we fail to convert from a source type to a
destination type for initialization, assignment, parameter-passing,
etc. The main issue fixed here is that we used rather confusing
wording for diagnostics such as
t.c:2:9: warning: initializing 'char const [2]' discards qualifiers,
expected 'char *' [-pedantic]
char *name = __func__;
^ ~~~~~~~~
We're not initializing a 'char const [2]', we're initializing a 'char
*' with an expression of type 'char const [2]'. Similar problems
existed for other diagnostics in this area, so I've normalized them all
with more precise descriptive text to say what we're
initializing/converting/assigning/etc. from and to. The warning for
the code above is now:
t.c:2:9: warning: initializing 'char *' from an expression of type
'char const [2]' discards qualifiers [-pedantic]
char *name = __func__;
^ ~~~~~~~~
Fixes <rdar://problem/7447179>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100832 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Parser/declarators.c
|
| 23e907ab9119ccfdff17b3808a770c5a6707fb95 |
|
14-Feb-2010 |
John McCall <rjmccall@apple.com> |
Improve the diagnostic given when referring to a tag type without a tag (in C)
or that's been hidden by a non-type (in C++).
The ideal C++ diagnostic here would note the hiding declaration, but this
is a good start.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@96141 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Parser/declarators.c
|
| c2e1c1af8ffe750b827284f207b9207112c7cc4e |
|
03-Feb-2010 |
Chris Lattner <sabre@nondot.org> |
Declarators can have grouping parens. This fixes rdar://7608537.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@95246 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Parser/declarators.c
|
| 16acfee729e00536af827935ccfcf69be721e462 |
|
03-Feb-2010 |
Chris Lattner <sabre@nondot.org> |
fix PR6216
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@95185 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Parser/declarators.c
|
| 99c952046600f6bfccf315aa7ad5b1be2d242cc3 |
|
02-Feb-2010 |
Chris Lattner <sabre@nondot.org> |
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@95094 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Parser/declarators.c
|
| 3e156ad9adc7332e626eedbc86aa4e3b03f17ca5 |
|
02-Feb-2010 |
Chris Lattner <sabre@nondot.org> |
improve diagnostics on missing ; in a struct. Before:
t.c:4:3: error: expected ';' at end of declaration list
int y;
^
t.c:4:8: warning: extra ';' inside a struct or union
int y;
^
t.c:6:1: warning: expected ';' at end of declaration list
};
^
After:
t.c:3:8: error: expected ';' at end of declaration list
int x // expected-error {{expected ';' at end of declaration list}}
^
;
t.c:5:8: warning: expected ';' at end of declaration list
int z
^
;
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@95038 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Parser/declarators.c
|
| a5728872c7702ddd09537c95bc3cbd20e1f2fb09 |
|
15-Dec-2009 |
Daniel Dunbar <daniel@zuster.org> |
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91446 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Parser/declarators.c
|
| d1969d803cfcc65f1c334df4cc89c7fdd33ee4c9 |
|
22-Jul-2009 |
Mike Stump <mrs@apple.com> |
Prep for new warning.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@76709 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Parser/declarators.c
|
| eb32fde032a250091134db56a3aeaea6b09f6594 |
|
28-Apr-2009 |
Eli Friedman <eli.friedman@gmail.com> |
Simplify the scheme used for keywords, and change the classification
scheme to be more useful.
The new scheme introduces a set of categories that should be more
readable, and also reflects what we want to consider as an extension
more accurately. Specifically, it makes the "what is a keyword"
determination accurately reflect whether the keyword is a GNU or
Microsoft extension.
I also introduced separate flags for keyword aliases; this is useful
because the classification of the aliases is mostly unrelated to the
classification of the original keyword.
This patch treats anything that's in the implementation
namespace (prefixed with "__", or "_X" where "X" is any upper-case
letter) as a keyword without marking it as an extension. This is
consistent with the standards in that an implementation is allowed to define
arbitrary extensions in the implementation namespace without violating
the standard. This gets rid of all the nasty "extension used" warnings
for stuff like __attribute__ in -pedantic mode. We still warn for
extensions outside of the the implementation namespace, like typeof.
If someone wants to implement -Wextensions or something like that, we
could add additional information to the keyword table.
This also removes processing for the unused "Boolean" language option;
such an extension isn't supported on any other C implementation, so I
don't see any point to adding it.
The changes to test/CodeGen/inline.c are required because previously, we
weren't actually disabling the "inline" keyword in -std=c89 mode.
I'll remove Boolean and NoExtensions from LangOptions in a follow-up
commit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70281 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Parser/declarators.c
|
| 6491f47670661c7c9e546cbc3ca7bae2f9850f21 |
|
13-Apr-2009 |
Chris Lattner <sabre@nondot.org> |
fix another case that assumed that GetTypeForDeclarator would never return null.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68918 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Parser/declarators.c
|
| 33c6ebef6f9acad6eb667fff77ff78f0c169332c |
|
13-Apr-2009 |
Chris Lattner <sabre@nondot.org> |
mark the declspec as invalid when we recover instead of forcing to int,
this allows downstream diags to be properly silenced.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68917 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Parser/declarators.c
|
| 4c97d762d8c5a84f6554e5bfb31d28c90df64158 |
|
12-Apr-2009 |
Chris Lattner <sabre@nondot.org> |
Diagnose invalid uses of tagged types with a missing tag. For example, in:
struct xyz { int y; };
enum abc { ZZZ };
static xyz b;
abc c;
we used to produce:
t2.c:4:8: error: unknown type name 'xyz'
static xyz b;
^
t2.c:5:1: error: unknown type name 'abc'
abc c;
^
we now produce:
t2.c:4:8: error: use of tagged type 'xyz' without 'struct' tag
static xyz b;
^
struct
t2.c:5:1: error: use of tagged type 'abc' without 'enum' tag
abc c;
^
enum
GCC produces the normal:
t2.c:4: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘b’
t2.c:5: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘c’
rdar://6783347
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68914 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Parser/declarators.c
|
| c199ab3ea1381e8e9cdd720eb87bb4f65cdf5086 |
|
12-Apr-2009 |
Chris Lattner <sabre@nondot.org> |
Implement the first set of changes for PR3963 and rdar://6759604,
which tries to do better error recovery when it is "obvious" that an
identifier is a mis-typed typename. In this case, we try to parse
it as a typename instead of as the identifier in a declarator, which
gives us several options for better error recovery and immediately
makes diagnostics more useful. For example, we now produce:
t.c:4:8: error: unknown type name 'foo_t'
static foo_t a = 4;
^
instead of:
t.c:4:14: error: invalid token after top level declarator
static foo_t a = 4;
^
Also, since we now parse "a" correctly, we make a decl for it,
preventing later uses of 'a' from emitting things like:
t.c:12:20: error: use of undeclared identifier 'a'
int bar() { return a + b; }
^
I'd really appreciate any scrutiny possible on this, it
is a tricky area.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68911 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Parser/declarators.c
|
| d7d5f0223bd30dfd618762349c6209dd1d5ea3e6 |
|
24-Mar-2009 |
Daniel Dunbar <daniel@zuster.org> |
Rename clang to clang-cc.
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
/external/clang/test/Parser/declarators.c
|
| 1f6f54be86a514d531ec231fd837858a43cfe72e |
|
11-Nov-2008 |
Chris Lattner <sabre@nondot.org> |
Fix PR3031 by silencing follow-on errors in invalid declarations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@59027 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Parser/declarators.c
|
| 3825c2eb00f108854942533a4993327889c081c3 |
|
06-Apr-2008 |
Chris Lattner <sabre@nondot.org> |
reject 'int test(x, x) int x; {}'
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@49271 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Parser/declarators.c
|
| aaf9ddbeab08a43203cf6b9ca4986c8c6fe6fdc6 |
|
06-Apr-2008 |
Chris Lattner <sabre@nondot.org> |
reject 'typedef int y; int test(x, y)'.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@49270 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Parser/declarators.c
|
| d658b562e80d6ef7a1118e34ff12802c6e2fcced |
|
05-Apr-2008 |
Chris Lattner <sabre@nondot.org> |
Fix handling of implicit int, resolving PR2012 and reverting (and
subsuming) my patch for PR1999.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@49251 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Parser/declarators.c
|
| 99d724f6a31b5521ded95adf10ef7f3c62a0b18e |
|
11-Feb-2008 |
Chris Lattner <sabre@nondot.org> |
Fix PR1999, by emitting a hard error only if an argument declarator is completely
missing. Otherwise, it is an implicit int case, which is valid in c90 and invalid
elsewhere, but accepted as an extension.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@46938 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Parser/declarators.c
|
| e0e713b661ed07b7e012147344220583a91ab1bf |
|
31-Jan-2008 |
Chris Lattner <sabre@nondot.org> |
Fix PR1965: missing diagnostics for parameters that are missing
type specifiers. This required updating some (buggy) tests, and the
testcase was previously accidentally committed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@46603 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Parser/declarators.c
|
| 68cfd49ea35d9101da9e6d4d5642263c9e95f1a4 |
|
19-Dec-2007 |
Chris Lattner <sabre@nondot.org> |
reenable this code, fix the testcase.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@45205 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Parser/declarators.c
|
| 5f016e2cb5d11daeb237544de1c5d59f20fe1a6e |
|
11-Jul-2007 |
Reid Spencer <rspencer@reidspencer.com> |
Stage two of getting CFE top correct.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@39734 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Parser/declarators.c
|