Fix for GENERATED_BODY() causing "expected a ;"?

This has been bugging me quite a while, since normally all macros that don’t have an effect on the following line should be terminated by a ; but this one isn’t and it messes with Visual Studios automatic error detection, causing incorrect parsing and thus any plugins to mess up. Is there any fix for this?

I know that building will make it fix itself, but once you change code it comes back again, since IntelliSense is only overriden by the most recent build.

Hey -

Can you elaborate on the problem you’re having? What class are you adding where the GENERATED_BODY() line is causing a compile issue? Can you add the exact error you’re running into? Can you also explain what macros you’re using that end with “;”? Engine macros (UCLASS, UPROPERTY, UFUNCTION, UENUM, USTRUCT) all end with () without a semicolon at the end. This goes for GENERATED_BODY as well.

Hey ,

it’s not a compile issue I’m having, it’s a dynamic parsing issue. This one macro is the only macro that I am having this issue with, as it doesn’t appear before anything that has a line termination character (semicolon). IntelliSense for example will warn about a missing semicolon on the line after it, plugins have an incredibly hard time parsing files with this in it (over 5 seconds to even find a reference in one file) and it messes up automatic indentation.

And adding a ; after it will make Unreals Precompiler ■■■■ itself with the message that there’s an extra ; after it. So how do I fix this without changing my workflow and coding standards?

IntelliSense often throws false errors due to the nature of the engine’s structure and how the Unreal Build Tool reads specific code. An alternative to IntelliSense would be to use Visual Assist X which is much smoother compatibility wise. You can try a free trial of Visual Assist, however the full version does require a paid license. As for plugin behavior, can you provide an example or simple setup for me to test locally as I have not noticed this behavior myself.

Well, Visual Assist X would be the primary example. Find References (limited to just the same project) takes ages, much longer than it does in this code for example.

Any way to fix the automatic indentation or am i forever stuck with one line being slightly further right than it should be? It looks horrible.

Apparently adding an empty comment after it helps somewhat. It will still indent the next empty line but not any code afterwards.

As you mentioned, Visual Studio reads the GENERATED_BODY() line the same way it reads the line of an if() statement and indents the following line since it expects the next line to be a continuation of the previous. This is also the case when using the UPROPERTY / UFUNCTION macros. Because this is inherent to how Visual Studio reads each line of code, there is no fix for the indention when returning from one of these lines. I believe Visual Studio has an option to disable automatic indention, however I have not used this as it would affect indention throughout Visual Studio which I would find to be more of a hindrance.

Cheers

So, when will this be fixed? Is it going to be another “never” reply?
Automatic Formatting is really helpful and this breaks it completely. You can’t put your own ; after GENERATED_BODY() as Build.bat complains about an extra ; before the next whatever.

Hey ,

As mentioned previously, the indention after the GENERATED_BODY() is due to how Visual Studio reads the line of code and there is no fix for this behavior.

Hey ,

I’m not sure if you even my comment or the question. Currently this syntax breaks every single visual studio plugin I have including Visual Assist X. A single search for reference takes hours when I’m inside a class that has a GENERATED_BODY() statement, and only a few minutes in normal structures and classes. This makes C++ coding a nightmare as you can’t just check where things were called from or what references this class.

The only thing that could fix this is if Build.bat (your build tool thingy) allows users to put a ; after that macro - which would also make it valid syntax again.

Can you explain exactly what you’re doing and the results you’re seeing? When using Visual Assist on my end I am able to find references in classes with the GENERATED_BODY line in a few seconds depending on the size of the class. If you can provide a specific example of the behavior you’re seeing versus what the expected would be, it will help me understand the issue better.

Sure. I have a class with just one method in it and the GENERATED_BODY() line. If I use any of the Visual Studios features (Peek Definition, Go To Definition/Declaration) it freezes and never unfreezes. If I use any Find References from Visual Assist, the window pops up and the loading bar progresses extremely slowly.
As soon as I remove the GENERATED_BODY() and UCLASS() line, both start working. Visual Studios features still freeze, but take less than 30 minutes to finish and unfreeze, while Visual Assist is done in less than a second.
Visual Studio, Unreal Engine and the project are on a M.2 SSD, so it’s not related to disk speed.