Download

[Linux] Clang 3.5 compilation error with -Werror and -Wshado

This is a copied post from answerhub - I’m having issues with Clang compilation on Linux, as described below. Any help would be greatly appreciated!


It seems Clang is a little rabid in terms of variable naming - because “-Wshadow” is set, attempting to compile a C++ class on Linux using Clang 3.5 results in a warning when a function parameter has the same name as data member. As the flag “-Werror” is also set, this warning gets promoted to a full-blown error and interrupts the build.

Dropping “-Werror” from the compilation arguments should theoretically make these issues a visual log annoyance instead of a blocking issue. GCC has had the same issue as a bug report, but has apparently fixed it.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57709

The provided sample code below compiles fine on Windows 7 using Visual Studio 2013 Community, but fails with the following error on Linux Mint 17.2, using Qt Creator and Clang 3.5.

Sample code:


 #pragma once
 
 #include "GameProject.h"
 #include "MemoryElement.generated.h"
 /**
  * 
  */
 USTRUCT()
 struct GAMEPROJECT_API FMemoryElement
 {
     GENERATED_USTRUCT_BODY();
 public:
     UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Memory")
         FString KeyName;
 
     UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Memory")
         FString Data;
 
     FMemoryElement()
     {
         KeyName = "";
         Data = "";
     }
 
     FMemoryElement(FString KeyName, FString Data)
     {
         this->KeyName = KeyName;
             this->Data = Data;
     }
 };

Compilation Error:


 In file included from /home/jarl/Programming/Unreal Projects/GameProject 4.8/Intermediate/Build/Linux/x86_64-unknown-linux-gnu/UE4Editor/Inc/GameProject/GameProject.generated.cpp:9:
 In file included from ../../../Unreal Projects/GameProject 4.8/Intermediate/Build/Linux/x86_64-unknown-linux-gnu/UE4Editor/Inc/GameProject/GameProject.generated.dep.h:21:
 ../../../Unreal Projects/GameProject 4.8/Source/GameProject/Dialogue/MemoryElement.h:27:25: error: declaration shadows a field of 'FMemoryElement' -Werror,-Wshadow]
         FMemoryElement(FString KeyName, FString Data)
                                ^
 ../../../Unreal Projects/GameProject 4.8/Source/GameProject/Dialogue/MemoryElement.h:16:11: note: previous declaration is here
                 FString KeyName;
                         ^
 ../../../Unreal Projects/GameProject 4.8/Source/GameProject/Dialogue/MemoryElement.h:27:42: error: declaration shadows a field of 'FMemoryElement' -Werror,-Wshadow]
         FMemoryElement(FString KeyName, FString Data)
                                                 ^
 ../../../Unreal Projects/GameProject 4.8/Source/GameProject/Dialogue/MemoryElement.h:19:11: note: previous declaration is here
                 FString Data;
                         ^
 

While workarounds are available (renaming member variables to have a trailing underscore, renaming the function parameter), it is a common idiom to give function parameters the same name as the variable they initialize or affect.

Distro: Linux Mint 17.2
Compiler: Clang 3.5
IDE: Qt Creator
Unreal Engine: 4.8.3 (Github 4.8 branch source build)

Yeah I’m hitting this problem as well, I’d rather this was an option since it’s not always going to cause you problems (AFAIK).

I’ve been reading through the UBT source, and it seems like there’s some sort of on/off switch for it. The relevant files (LinuxToolChain.cs, MacToolChain.cs, IOSToolChain.cs) contain this little piece of code:



if (CompileEnvironment.Config.bEnableShadowVariableWarning)
{
	Result += " -Wshadow";
}


There’s support for turning it off somewhere. I couldn’t find the configuration file, though. It may be UEBuildModule.cs, although I don’t see where one would do it.

Is there some sort of eldritch ritual we could try to use and summon an engine dev to shed some light on this? x)

You can flip that switch either directly in BuildConfiguration.cs (see Configuring Unreal Build System | Unreal Engine Documentation) or in BuildConfiguration.xml which you can put in Engine/Saved/UnrealBuildTool. However, disabling -Wshadow is ill advised since variable shadowing is prone to bugs and has bitten us in the past (people routinely forget this->). We have -Wshadow off by default because VS 2013 doesn’t support an equivalent switch, but since VS 2015 introduced its support this will be likely the default setting on all platforms.

Thanks, RCL! I understand the issue a bit more now.

Would adding



<bEnableShadowVariableWarning>false</bEnableShadowVariableWarning>


to the XML file be enough? I don’t see any mention of it in the link you provided.