History log of /external/clang/test/Parser/declarators.c
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
176edba5311f6eff0cad2631449885ddf4fbc9ea 01-Dec-2014 Stephen Hines <srhines@google.com> Update aosp/master Clang for rebase to r222490.

Change-Id: Ic557ac55e97fbf6ee08771c7b7c3594777b0aefd
/external/clang/test/Parser/declarators.c
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