-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Get rid of parser hacks related to typedefs and identifiers #107
Labels
area:parser
The C language parser Cesium uses
kind:refactor
Internal changes not affecting the compiler behavior
status:blocked
For issues blocked by something
Comments
ForNeVeR
added
kind:refactor
Internal changes not affecting the compiler behavior
area:parser
The C language parser Cesium uses
status:blocked
For issues blocked by something
labels
Feb 17, 2022
There additional cases where Cesium chokes in completely different ways.
First one have this AST
Second one is this
|
This issue is what currently blocking #61 from progressing. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
area:parser
The C language parser Cesium uses
kind:refactor
Internal changes not affecting the compiler behavior
status:blocked
For issues blocked by something
In the C17 standard, a common pair of AST nodes which are frequently used together are
declaration_specifiers
and something involving anidentifier
next.Some examples are (Yoakke syntax, not direct EBNF from the standard):
declaration: declaration_specifiers init_declarator_list? ';'
struct_declaration: specifier_qualifier_list struct_declarator_list? ';'
(wherespecifier_qualifier_list
includes some of thedeclaration_specifiers
)The problem is that
declaration_specifiers
(or, say,specifier_qualifier_list
) include an item calledtypedef_name
, which it is: a name of atypedef
item.This causes Cesium to choke on simple definitions such as
size_t foo
: was ittypedef_name: size_t
andtypedef_name: foo
, ortypedef_name: foo
andidentifier: foo
?Ideally, a parser should be able to choose in most contexts, since the former isn't even valid. But due to Yoakke issue LanguageDev/Yoakke#138, currently we have to support a great number of workarounds to be able to parse even the simplest of cases.
Current plan is to wait for the Yoakke issue to get resolved, and then remove all the hacks from the code.
To find all of these hacks, look for marks like
TODO[#107]
.Blocked on:
The text was updated successfully, but these errors were encountered: