Whole Tomato Software Forums

Whole Tomato Software Forums

All Forums

Visual Assist

Technical Support

bug: parser error

You must be registered to post a reply.
Click here to register.

Screensize:

UserName:

Password:

Format:

Message:

Forum code is on.
Html is off.

Check to include your profile signature.
Check to subscribe to this topic.

T O P I C R E V I E W
omigamedev	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.
6 L A T E S T R E P L I E S (Newest First)
feline	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.
omigamedev	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	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
sean	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?
feline	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 }
feline	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.

Snitz Forums 2000