[Bug] Naming Conflictions in Blueprints (code C2039)

Development Programming & Scripting Blueprint
, , , ,
1

How to reproduce: in one module, create a class that extends from UObject and create a property with the UPROPERTY macro and name it something unique. In a separate class, create a function (with the UFUNCTION macro) that accepts an argument with the same name, but the name may start with a lowercase letter On compilation, C2039 is thrown and UnrealHeaderTool reports that the first class (which contains the property) does not contain the given member.

Example, for UMyFirstClass:

UPROPERTY(BlueprintReadOnly, Category = "SomeCategory")
FVector2D SomeName;

And then for UMySecondClass (notice the case difference)

UFUNCTION(BlueprintCallable, Category = "SomeOtherCategory")
void RandomFunction(FVector2D someName);

The thrown error is:

C2039: 'someName' : is not a member of 'UMyFirstObject'

Followed by a 2661 generated by the boilerplate (both errors are in the boilerplate .generated.inl file)

Why is it looking for the case-sensitive name of the function argument inside a completely different class?

I can reproduce this reliably on my side. This is definitely expected behavior for things within the same class, because of the way Blueprints will extract the names of properties and make getters/setters out of them, but it shouldn’t be a phenomena happening between entirely different classes. I’ve played around with it and have so far been convinced this is not desired behavior.

  • Havlik
2

Some more info.

So it looks like you can have getter/setter functions that resemble the following without throwing the error:

UFUNCTION(BlueprintCallable, Category = "Physics")
float GetFriction() const;

UFUNCTION(BlueprintCallable, Category = "Physics")
void SetFriction(float friction);

That is, the problem only arises when UPROPERTY is thrown into the equation.

3

UnrealBuildTool makes use of FNames during code generation and since the FName table is global the first version of the name that it finds establishes the casing.

We are aware this is not exactly ideal and some thought is being put in to how to resolve it, however it will likely require some substantial rework of UBT so I can’t provide any kind of timeline.

Apologies for the inconvenience.

4

Thanks for the quick answer Marc. FNames aren’t case sensitive?

5

We’ve made a change for 4.5 which will make FName case-preserving for the editor and UHT. This should address the FName case issues you’ve been seeing.

I’ve checked that you’re able to rename asset, actor, and blueprint components in a way that changes only their case. I’ve also tested that you’re able to have a variables in different UObject/UStruct types that vary only by case, and that the UHT will generate code that actually compiles.