Compiler or UHT not checking everything
I enabled the compiler to throw errors on shadow variable errors:
After making this change and hitting F5 there are no compilation errors. Then I added a new UPROPERTY and initialized it in the cpp file and then suddenly that file and another file (which remained completely unchanged by me) threw shadow variable compiler errors. The code that that the shadow-errors applied to was not changed between the working compile and the one that threw errors.
So why did the compiler not throw me this error when I pressed F5 the first time? Well.. I assume that this is related to this: https://answers.unrealengine.com/questions/730763/object-finder-cannot-convert-ustaticmesh-to-uobjec.html
and https://answers.unrealengine.com/questions/730088/how-can-a-forward-declaration-cause-undefined.html and some other posts that I forgot.
I believe that the compiler/UHT don't check files that were already compiled successfully previously and stores/caches those in some way. Files are probably grouped together for compilation and if even one of those files is changed (even if it's a useless comment that was added), the whole group get's recompiled or at least re-checked. That would explain why ctrl+z spamming the code back to the original state were it used to compile doesn't compile.
This mechanic may be good for saving on compilation time for big projects but it also causes the compiler to not throw errors when it should. And sometimes I even see old files that should no longer compile (but they do as long as I never touch them nor the 'group' they belong to anymore) due to missing includes or more graves mistakes from me. But in the past I got them to compile and then they are never checked anymore by the compiler/UHT?
I'm posting this in the bug reports section. My apologies if this is intended behavior but then please let me know why. So far nobody could answer it. I have heard various wild theories but nobody could tell me what exactly is happening.
Sorry for the delay in responding to your post. Are you still having trouble with this issue? If so, we have a new process for reporting Engine bugs. If you are still having trouble with this, please fill out the forum on our Report a Bug page with as much information as you have available.
answered Sep 07 '18 at 08:17 PM
Note that I am posting this as an answer because of the comment-character-limitation.
I just had another compiler error on this line:
So I pressed F12 on UStaticMesh and ended up in EngineType.h on line 2522:
Erm... Yeah... That kinda explains... First of all this is a forward declaration (which causes the compiler error) and secondly that is not the one from Engine/MeshComponent.h that I was expecting.
Now here comes the interesting part. This class compiles and uses the proper UStaticMesh (inherits from the same base class as the other one):
And this one does not and uses the one from EngineType.h:
So 2 classes that aside from their name are exactly identical (okay I outcommented some unrelated lines for testing purposes in the second one but it made no difference). One compiles and one does not.
But it get's even worse. After adding the include #include "Engine/StaticMesh.h" manually to the one that didn't compile and then removing that include again still caused the second one to magically compile (yes without the include this time). Yes my code is EXACTLY the same as before when it did not compile but now it uses the proper UStaticMesh include... Erm... There has got to be some kind of caching bug somewhere... I mean, sometimes I just have files that pseudo-randomly give compiler errors (without being changed) completely out of the blue and they ask for includes that they never required before (and now apparently) vice versa as well. And on top of that other classes that are nearly identical don't require those include (but may do so at a later time for unknown reasons).
The workaround is obviously to use the specific includes and force the UHT/compiler to use the proper ones (which might be considered better code anyway). But why it sometimes uses the one from include A and sometimes the one from include B for the exact same class... No idea... It could be intended behavior but its' weird. And it also (a bit) beats the purpose of including
Follow this question
Once you sign in you will be able to subscribe for any updates here