-
-
Notifications
You must be signed in to change notification settings - Fork 114
Preprocessor failure on various prototypes. #30
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
Comments
Thank you! I'll take a look at it in the next weeks. Can you tell if adding the prototype yourself works around the issues? |
Also, what would be the correct prototypes? |
Yes adding a prototype does prevent the incorrect generation. But without it, the errors are very confusing if you aren't expecting it. Here is an example of the errors for 2 (simple function returning a function pointer)
|
The prototypes are an exact copy, the functions are correct as written, just without the |
I suspect that this is mostly because the line numbers are completely screwed up? I previously discussed an approach with Federico to generate a #line directive for every generated prototype, pointing to the original function definition, which should at least improve this. |
These are the outputs of ctags for 2, 3 and 4 https://gist.github.com/ffissore/625f6743e8f643311ad8 |
note: |
That is ok, the function name is
I would not go there - AFAICS the function "declaration" is just the entire line, which might even contain a full function body (like One generic way would be to see if the original declaration matches the generated prototype. If so, you're probably good, if not, skip generating the prototype? |
yes, indeed. I think it's best when limitations are known and an easy
if the prototype ALWAYS equal to its related function? |
Note sure what you mean there? What I mean is that for example, for:
the generated prototype (based on returntype, name and signature) is Looking at:
the generated prototype is |
This is what I came up with: https://github.com/arduino/arduino-builder/commits/functionpointer |
Also, this next one relates to #27 / arduino/ctags#1 The space is removed between I have added a PR here: arduino/ctags#3
|
However the issue above is still not solved completely. The space should be fixed by the PR, however the template parameters are removed.
|
I found another case that is still broken with the functionpointer branch:
Which generates:
Because the new code does a "substring" test, the prototype ( |
I added a commit to https://github.com/arduino/arduino-builder/commits/functionpointer that changes the matching to prefix matching instead of substring matching, which fixes the static function prototype. I tried doing full exact matching, by taking the code line up to the first {, if any, but that failed when a function definition was followed by a comment before the {. To prevent having to parse comments as well, I switched to prefix matching instead. Since, AFAICS, only function attribute can appear after a function's argument list (and it's not needed to specify those on both the definition and the prototype), I don't think this will generated any broken prototypes. |
Let's recap. @Chris--A all your cases are now handled and no wrong prototype is added. The IDE won't cast its magic on these sketches, not on all function at least, so the only way to compile them is to add prototypes yourself |
Nice, will pull & rebuild. |
1. C++11 trailing return types.
This problem isn't really a big issue, a user can simply add a prototype or define above the code where it is called from (preprocessor ignores completely). Its the next problems which cause quite a disaster.
2. Returning a function pointer.
This causes a complete failure as the prototype is generated wrong. As the generated prototype differs only by return type, the function is ambiguous and the compiler cannot continue.
3. Returning an array reference.
Just like problem 2, the function prototype is incorrectly generated.
4. Combining 2 & 3
Here is a function which accepts and returns: A reference to an array of function pointers which take and
int
as a parameter and return nothing.Bare with me, I know the example below is a little abnormal, its the preprocessor that is interesting.
And the resulting cpp:
As you can see, the preprocessor has correctly copied the functions parameter, but completely removed the return type (apart from the
void
).If you need help, point me in the right direction and I can 'go' have a bit of an investigation.
Or is this a problem within the ctags repo?
I'm just having fun breaking things, I'm sure I'll have a few more additions to my list in the future.
The text was updated successfully, but these errors were encountered: