[FEATURE REQUEST] Make UObject macros not wreck intellisense

[Zeblote]

So, there's this incredibly annoying problem where you have to re-open VS to make intellisense work again after modifying headers.
Any small change will completely prevent it from being useful:





All because the macro expects to find code at a specific line:





Why don't you simply define all of the UObject macros as nothing for intellisense?

[Sixmorphugus]

Most people tend to just work with this but I do agree it's annoying having to ignore all those red underlines because you changed a file. Support.

[Ben Marsh]

That's a good idea! I'll try to get that fixed for 4.18.

[Zeblote]

That's a good idea! I'll try to get that fixed for 4.18.

Great, thanks!

[Ben Marsh]

I've implemented this today. It's not up on GitHub yet (it's in a private development stream for now), but it will be in the 4.18 release. If you're interested to make the changes locally, they are all in ObjectMacros.h:

Adding the check for __INTELLISENSE__ here prevents classes being parsed if the generated code is out of date:

#if UE_BUILD_DOCS || defined(__INTELLISENSE__ )
#define UCLASS(...)
#else
#define UCLASS(...) BODY_MACRO_COMBINE(CURRENT_FILE_ID,_,__LINE__,_PROLOG)
#endif

Adding semi-colons at the end of these lines allows the Intellisense compiler to recover before the next declaration if the expanded macro is missing:

#define GENERATED_BODY_LEGACY(...) BODY_MACRO_COMBINE(CURRENT_FILE_ID,_,__LINE__,_GENERATED_BODY_LEGACY);
#define GENERATED_BODY(...) BODY_MACRO_COMBINE(CURRENT_FILE_ID,_,__LINE__,_GENERATED_BODY);

Interestingly, most devs at Epic use Visual Assist X, which handles both these situations fine (which is probably why we didn't spot them).

[John Alcatraz]

I've implemented this today. It's not up on GitHub yet (it's in a private development stream for now)

Thanks for describing the fix here, but since you just mentioned that, please try to fix the situation with the private branches more quickly. 1 or 2 years ago we had access to all the individual commits since they were merged into master directly, but for a way too long time we now have to wait for those huge merges from the dev branches into master that often take more than 1.5 months to get into master and make it impossible for us to quickly see what lines on what file a commit actually changed, no way for us to cherry pick a commit or anything like that. It's a quite horrible situation for everyone who doesn't have perforce access with the dev branches.
I know you're working on fixing that, but its like this for a way too long time now, please don't forget about how awful the current situation is for people who works a lot with the UE4 source.

You probably know that a while ago the dev branches were actually mirrored to your own github account (ben-marsh), and that was very nice. I expected that to be the test for how it will look like on the official UE4 github shortly after, but you just stopped mirroring the branches to your repo and they are still not in the UnrealEngine repo.

[Zeblote]

Interestingly, most devs at Epic use Visual Assist X, which handles both these situations fine (which is probably why we didn't spot them).

Huh, do they just completely disable intellisense then? I'm also using visual assist (as you can see by the pretty colors) and it's still all underligned. Maybe I've set it up wrong.

[Zeblote]

huge merges

Maybe you'll like huge merges with no descriptions more?
https://github.com/EpicGames/UnrealE...55631645127b5c

[John Alcatraz]

Maybe you'll like huge merges with no descriptions more?
https://github.com/EpicGames/UnrealE...55631645127b5c

Yeah, that merge from yesterday actually made me quite sad. Not only do we not have access to the individual commits, now they also didn't even add the description so we have no idea what changed in those 27k lines of changes... That's definitely a new low. I honestly don't understand how epic expects us to work with this.
I really like the UE4 source, its nice and clean and a lot of fun to work with, but this administrative issue with the branches and master is way too relevant for being ignored for so long...

[Ben Marsh]

Yeah, I had mirroring to GitHub working to my personal repo as a test for a while. It all worked, it's ready to go, but there are concerns that having a live mirror exposes us to a lot of legal issues given the number of NDA-only platforms we work on. We've had leaks in the past, and having a live mirror of changes that developers make without the appropriate security mechanisms in place would just make it likely that it would happen in the future. It's being worked on, it's just a slow process.

[John Alcatraz]

Yeah, I had mirroring to GitHub working to my personal repo as a test for a while. It all worked, it's ready to go, but there are concerns that having a live mirror exposes us to a lot of legal issues given the number of NDA-only platforms we work on. We've had leaks in the past, and having a live mirror of changes that developers make without the appropriate security mechanisms in place would just make it likely that it would happen in the future. It's being worked on, it's just a slow process.

I understand that there are issues associated with it, but it feels a bit as if its not a very high priority for you to fix, since we now are without access to the commits for a long, long time. It would have been fine for a few weeks or so, but years is just way too much.

You could just let a few people manually flag every commit as "no NDA stuff in here" or something like that until you have a better solution, we just really need something. I think devs usually know when they worked on some platform that isn't public yet or something like that, so maybe they could just check a checkbox on commiting to prevent it from being public? Its just really bad if we can't have access to 99.99% of the commits because 0.001% have NDA stuff in them. And you probably had ways to prevent that back when you merged everything into master directly? The worst that could happen for us is that it takes another year before you found some solution and we are left in the dark for another way too long time. Just please think about anything to make the situation more acceptable for us in the near term. Please don't let the "slow process" last for 5 years.
You know there are a lot of awesome programmers that want to do a lot of awesome stuff with UE4, and this is just a major handicap currently.

[Zeblote]

legal issues given the number of NDA-only platforms we work on.

That's... it? Come on, really. Each private platform can have its own private branch, public commits are scanned to make sure they don't mention the existance of this platform. Job done.

I don't see how this can hold anything back for years.

[Zeblote]

I've implemented this today

So, I just added this, now every time I build anything all of the engine modules are re-linked for no reason. I'm not sure if caused by this or updating to version 15.3 though...


Edit: solved that problem with another full rebuild