"# include" (with a space) is ignored for dependency parsing in UHT

When you have a space after the pound sign for an include (or any other preprocessor directive), the statement is silently ignored by UHT when scanning for dependencies, even though this is perfectly valid preprocessor syntax.

This is problematic because it can cause UHT to not pick up dependencies for a file when generating the header metadata.

Specifically, FHeaderParser::SimplifiedClassParse needs to be updated to support whitespace after #

Hi Joergen,

Would it be possible to get an example where this is failing for you? I tried a simple setup using # include instead of #include, and didn’t run into any problems.

Foo.h:

#pragma once

#include "Foo.generated.h"

USTRUCT()
struct FFoo {
    UPROPERTY()
    bool bReproduces;
};

Bar.h:

# include "Foo.h"
#include "Bar.generated.h"

USTRUCT()
struct FBar {
  UPROPERTY()
  TArray<FFoo> Foos;
};

It might depend on the arbitrary order that Foo.h and Bar.h are processed in, so if it doesn’t repro, try moving the structs around?

Hi Joergen,

I had a to dig into this issue again today, and I think I may have reproduced it. When you see this happening, did you see the following error in the build output in Visual Studio?

Unrecognized type 'FBar' - type must be a UCLASS, USTRUCT or UENUM

Yes, that is what it errored out with

It does appear to have something to do with the order in which the structs/header files are compiled. I am trying to narrow it down now.

I believe it’s because FHeaderParser::SimplifiedClassParse is not parsing the #include properly, which is causing it to not add that header as a dependency, so the order isn’t right.

Hi Joergen,

The only way that I was able to get this to reproduce consistently was by adding a struct to a header file, then adding a second struct to a second header file that referenced the first struct. Once that was built, I had to essentially switch the structs so that the first one was now referencing the second one, and add a space in the include that I added to the first header file. It was a somewhat complicated repro, so if you are aware of a simpler method of reproducing the issue, that would be helpful.

I have entered ticket UE-36390 to have this investigated further.