Repository navigation
Conversation
- Add support for declarations like `int (* __attribute__((stdcall)) fptr)(void)` - Fix regression introduced in inducer#54, which caused function pointer information to be discarded in case any attributes or asm labels were present
| from pycparserext.ext_c_parser import GnuCParser | ||
| p = GnuCParser() | ||
| ast = p.parse(src) | ||
| ast.show() | ||
|
|
||
| from pycparserext.ext_c_generator import GnuCGenerator | ||
| print(GnuCGenerator().visit(ast)) |
There was a problem hiding this comment.
While this tests that the parser and generator digest these, I would prefer a round-trip test asserting that the same code is generated again.
|
While trying to come up with more test cases for the round-trip tests I found myself staring at what generator produced for this code: int __attribute__((stdcall)) func1(void);
int func2(void) __attribute__((stdcall));generated code: __attribute__((stdcall)) int func1(void);
int func2(void) __attribute__((stdcall));I was puzzled why the attributes were located at different places in the generated code, while I thought they were put in the same place. It appears that they do not, with the former line putting the attributes into the Will probably brush up this PR and dive a little bit deeper into the topic to better understand what is happening and how it should happen, probably coming with more PRs. |
|
Should be ready to merge. I was not able to make the |
|
You could make an "abbreviated" Also, please fix the linter failures. |
Do you intend to compare the original source code to the generated? Or do you mean checking that after regenerating the code two times (src -> AST1 -> regen1 -> AST2 -> regen2) regen1 == regen2? The former will fail because the AST does not store, for example, the exact attribute position and it will get moved. The latter will work, but it would not catch all the cases that the current comparison does. For example, it might just discard the attribute information and it will pass the test, even though it is horribly wrong. |
|
|
||
| # _round_trip_matches trips at comparing the function | ||
| # specifiers here, as they are lists | ||
| # (how was this supposed to work, again?) |
There was a problem hiding this comment.
What do you mean here? If something has broken semantics, just fix it.
There was a problem hiding this comment.
I think it has broken semantics, but I don't know how to fix it yet. It requires a bit more research into the codebase.
But there might be a source representation that's exactly reproduced. We could parse and regenerate that. Then, additional strings could be provided that are supposed to result in equivalent ASTs. |
|
Yeah, it is possible, but I want to be able to test that attributes are parsed correctly in all possible places, not only in their "canonical" form. That's why it's problematic.. |
I agree with that goal. That's where I was going with the proposal of additional strings that parse/regenerate to the same canonical AST. |
|
So, you want them in addition to what I already have? Probably can do that |
Yeah, if the "reproduces canonical form" thing is easy to do, I'd appreciate having it. If it's not easy, don't bother though. |
|
I won't be pursuing this in any near time, sorry |
int (* __attribute__((stdcall)) fptr)(void)