Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 340773

Summary:	Unexpected syntax error for a struct declaration containing an extended keyword
Product:	[Tools] CDT	Reporter:	Richard Horbach <richard.horbach>
Component:	cdt-parser	Assignee:	Project Inbox <cdt-parser-inbox>
Status:	RESOLVED WORKSFORME	QA Contact:	Markus Schorn <mschorn.eclipse>
Severity:	normal
Priority:	P3	CC:	cdtdoug
Version:	8.0
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:

Description Richard Horbach

2011-03-23 11:06:25 EDT

Build Identifier:  M20100909-0800

Our compiler specific additional keywords are passed to the parser, by extending AbstractScannerExtensionConfiguration. For example we add keywords like '__far' and '__packed__'.

The keywords are recognized by the parser, since they are displayed in the proper format (bold and syntax highlighting is working).

Typically a keyword is allowed before or after the type it qualifies. For example both forms to qualify an integer to be located in far memory are allowed and are considered to be equal:
__far int i; // parser ok
int __far i; // parser ok
No parser error for these definitions are given.

Now I try to specify a packed structure. Our compiler accepts both forms, but the parser gives a syntax error for the first form.
struct __packed__ S; // parser gives a syntax error
__packed__ struct S; // parser ok

This is not consistent behaviour and I consider this an error in the parser.

Reproducible: Always

Steps to Reproduce:
1. Pass keyword __packed__ as additional keyword to the parser/scanner.
2. Open a test.c file, containing the code line 'struct __packed__ S;'.
3. A syntax error is given.

Comment 1 Markus Schorn

2011-03-28 10:33:08 EDT

The problem depends a lot on the implementation of your scanner extension configuration. Please provide the implementation.

Comment 2 Richard Horbach

2011-03-29 05:14:21 EDT

I rather don't want to upload our sources to bugzilla, so I will send them -along with some notes- to you directly.

The GNU notation using attributes is like this:
(1) struct test_t { } __attribute__((__packed__));

TASKING style (short) notation:
(2) struct __packed__ { } test_1;

or alternatively:
(3) __packed__ struct { } test_1;

My problem is that the GNU parser does accept notation (3), but does not accept notation (2).

Comment 3 Markus Schorn

2011-03-30 10:39:07 EDT

(In reply to comment #2)
Modelling __packed__ as an alternative decl-specifier (IExtensionToken.t__otherDeclSpecModifierFirst) does not work because the keyword struct cannot be followed by such a modifier. For example it is valid to use 'const struct { ...} x;', however you can't have 'struct const { ...} x;'

If you simply define __packed__ to be the empty token, all three examples parse fine:
public class CustomLanguage extends GCCLanguage {
	protected static final GCCScannerExtensionConfiguration SCANNER_EXT= 
		new GCCScannerExtensionConfiguration() {
		{
			addMacro("__packed__", "");
		}
	};

	@Override
	public String getId() {
		return "customLanguage.customid";
	}

	@Override
	protected IScannerExtensionConfiguration getScannerExtensionConfiguration() {
		return SCANNER_EXT;
	}
}

Comment 4 CDT Genie

2011-03-30 11:23:02 EDT

*** cdt cvs genie on behalf of mschorn ***
Bug 340773: Correctly consider alternate decl-specifiers.

[*] AbstractGNUSourceCodeParser.java 1.159 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt-core/org.eclipse.cdt.core/parser/org/eclipse/cdt/internal/core/dom/parser/AbstractGNUSourceCodeParser.java?root=Tools_Project&r1=1.158&r2=1.159

Comment 5 Richard Horbach

2011-03-31 10:56:08 EDT

(In reply to comment #3)

> If you simply define __packed__ to be the empty token, all three examples parse
> fine:

I will use the workaround as you suggest. Thanks.