| Author |
 Topic  |
|
|
omigamedev
New Member
2 Posts |
 Posted - Jan 07 2019 : 08:26:25 AM
|
Hi I'm not sure when this happened but I recently discovered that the parser goes banana when I have some objective code in an #ifdef block that is not even defined. The block contains objective-c code with the inline block ^{etc... and all the objc style [[[]]] going on. Now all the functions containing these blocks don't get parsed correctly and I cannot see them in the searching for symbols or references, they totally get ignored which makes everything inconsistent and I cannot rely on the refactoring tools anymore.
|
|
|
feline
Whole Tomato Software
United Kingdom
19022 Posts |
Posted - Jan 07 2019 : 09:46:01 AM
|
The problem is happening because VA is designed to parse code inside #ifdef blocks, so we can help you with this code, and be active inside this code. However, this does assume that the code is valid C++ code, but since this is IOS specific, it is confusing our parser. We are looking to improve our understanding of which code is active and which code is inactive:
case=42316
for now though, would editing this code a bit be an option? I am wondering about fooling VA into ignoring this code. |
zen is the art of being at one with the two'ness |
 |
|
|
feline
Whole Tomato Software
United Kingdom
19022 Posts |
Posted - Jan 07 2019 : 12:06:02 PM
|
It's not very nice, but I have found a work around that fixes these problems, at least in my tests. I am replacing the IOS specific code with a macro, and having the macro expand to be the IOS specific code. So, taking a simple example, this code:
void testIOSOne()
{
#ifdef __IOS__
[[PHPhotoLibrary sharedPhotoLibrary] performChanges:^{
}
#endif
}
that is confusing VA, becomes instead:
#define IOS_MULTILINE_CODE [[PHPhotoLibrary sharedPhotoLibrary] performChanges:^{ }
void testIOSOne()
{
#ifdef __IOS__
IOS_MULTILINE_CODE
#endif
}
|
zen is the art of being at one with the two'ness |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Jan 07 2019 : 12:06:29 PM
|
I know that adding support for C++17 attributes caused problems for us when we encountered objective-c syntax in __OBJC__ blocks, so we ignore any __OBJC__ block (behavior changed in 2291/2291.5). We can add a similar change for __IOS__, but might that be too aggressive?
|
Edited by - sean on Jan 07 2019 12:08:22 PM |
|
|
|
feline
Whole Tomato Software
United Kingdom
19022 Posts |
Posted - Jan 08 2019 : 07:49:22 AM
|
Unfortunately in my testing __OBJC__ blocks help sometimes, but not with the test case I have generated based on the code in the picture here. I have put in a bug report for this, since it would be nice to have a better work around while we work towards more complete handling of inactive code blocks:
case=134623 |
zen is the art of being at one with the two'ness |
|
|
|
omigamedev
New Member
2 Posts |
Posted - Jan 08 2019 : 10:21:13 AM
|
Thanks for the answer, I will end up refactoring the code block into another objc file and replace the block with a clean function call.
I hope this will help you improve your awesome software.
Cheers. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19022 Posts |
Posted - Jan 08 2019 : 10:49:48 AM
|
That does seem like the best solution for now. Hopefully you don't have to many blocks of Objective C code to extract.
Thank you for the bug report though, this has shown up a bug with our "ignore this and be happy" code, which is good to be aware of. |
zen is the art of being at one with the two'ness |
|
|
| |
Topic |
|
bug: parser error
