Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

declaration of 'xxx' hides previous local declaration #10814

Closed
peteshand opened this issue Oct 6, 2022 · 3 comments
Closed

declaration of 'xxx' hides previous local declaration #10814

peteshand opened this issue Oct 6, 2022 · 3 comments

Comments

@peteshand
Copy link

Hey there

I was wondering if anyone has some advice on an issue I'm facing.
It seems like in certain cases hxcpp (and possibly other targets) outputs code where temporary variables share the same name within the same scope.

for example the following works without issue:

class ScopeTest {
    public function new(){
        var a:Array<Dynamic> = [];
        
        a.map(function(i:Dynamic):Dynamic{
            trace("test1");
            return i;
        });

        a.map(function(i:Dynamic):Dynamic{
            trace("test2");
            return i;
        });
    }
}

this will generate cpp along the lines of:

::cpp::VirtualArray a = ::cpp::VirtualArray_obj::__new(0);
HXLINE(   7)		{
HXLINE(   7)			::cpp::VirtualArray result = ::cpp::VirtualArray_obj::__new(a->get_length());
HXDLIN(   7)			{
HXLINE(   7)				int _g = 0;
HXDLIN(   7)				int _g1 = a->get_length();
HXDLIN(   7)				while((_g < _g1)){
HXLINE(   7)					_g = (_g + 1);
HXDLIN(   7)					int i = (_g - 1);
HXDLIN(   7)					{
HXLINE(   7)						 ::Dynamic i1 = _hx_array_unsafe_get(a,i);
HXLINE(   8)						::haxe::Log_obj::trace(HX_("test1",9f,7f,95,0d),::hx::SourceInfo(HX_("src/ScopeTest.hx",e3,fb,eb,d6),8,HX_("ScopeTest",e6,9f,d9,b1),HX_("new",60,d0,53,00)));
HXLINE(   7)						result->__unsafe_set(i,i1);
            					}
            				}
            			}
            		}
HXLINE(  12)		{
HXLINE(  12)			::cpp::VirtualArray result1 = ::cpp::VirtualArray_obj::__new(a->get_length());
HXDLIN(  12)			{
HXLINE(  12)				int _g2 = 0;
HXDLIN(  12)				int _g3 = a->get_length();
HXDLIN(  12)				while((_g2 < _g3)){
HXLINE(  12)					_g2 = (_g2 + 1);
HXDLIN(  12)					int i = (_g2 - 1);
HXDLIN(  12)					{
HXLINE(  12)						 ::Dynamic i1 = _hx_array_unsafe_get(a,i);
HXLINE(  13)						::haxe::Log_obj::trace(HX_("test2",a0,7f,95,0d),::hx::SourceInfo(HX_("src/ScopeTest.hx",e3,fb,eb,d6),13,HX_("ScopeTest",e6,9f,d9,b1),HX_("new",60,d0,53,00)));
HXLINE(  12)						result1->__unsafe_set(i,i1);
            					}
            				}
            			}
            		}
            	}

of interest is int _g = 0; and int _g2 = 0;
However the issue arises when one of the map calls is nested within another block, but in the same function.
for example:

class ScopeTest {
    public function new(){
        var a:Array<Dynamic> = [];
        var i = 5;
        while (i > 0){

            a.map(function(i:Dynamic):Dynamic{
                trace("test1");
                return i;
            });
            i--;
        }
        

        a.map(function(i:Dynamic):Dynamic{
            trace("test2");
            return i;
        });
    }
}

This will generate cpp that defines int _g = ... twice:

HXLINE(  21)		::cpp::VirtualArray a = ::cpp::VirtualArray_obj::__new(0);
HXLINE(  22)		int i = 5;
HXLINE(  23)		while((i > 0)){
HXLINE(  25)			{
HXLINE(  25)				::cpp::VirtualArray result = ::cpp::VirtualArray_obj::__new(a->get_length());
HXDLIN(  25)				{
HXLINE(  25)					int _g = 0;
HXDLIN(  25)					int _g1 = a->get_length();
HXDLIN(  25)					while((_g < _g1)){
HXLINE(  25)						_g = (_g + 1);
HXDLIN(  25)						int i = (_g - 1);
HXDLIN(  25)						{
HXLINE(  25)							 ::Dynamic i1 = _hx_array_unsafe_get(a,i);
HXLINE(  26)							::haxe::Log_obj::trace(HX_("test1",9f,7f,95,0d),::hx::SourceInfo(HX_("src/ScopeTest.hx",e3,fb,eb,d6),26,HX_("ScopeTest",e6,9f,d9,b1),HX_("new",60,d0,53,00)));
HXLINE(  25)							result->__unsafe_set(i,i1);
            						}
            					}
            				}
            			}
HXLINE(  29)			i = (i - 1);
            		}
HXLINE(  33)		{
HXLINE(  33)			::cpp::VirtualArray result = ::cpp::VirtualArray_obj::__new(a->get_length());
HXDLIN(  33)			{
HXLINE(  33)				int _g = 0;
HXDLIN(  33)				int _g1 = a->get_length();
HXDLIN(  33)				while((_g < _g1)){
HXLINE(  33)					_g = (_g + 1);
HXDLIN(  33)					int i = (_g - 1);
HXDLIN(  33)					{
HXLINE(  33)						 ::Dynamic i1 = _hx_array_unsafe_get(a,i);
HXLINE(  34)						::haxe::Log_obj::trace(HX_("test2",a0,7f,95,0d),::hx::SourceInfo(HX_("src/ScopeTest.hx",e3,fb,eb,d6),34,HX_("ScopeTest",e6,9f,d9,b1),HX_("new",60,d0,53,00)));
HXLINE(  33)						result->__unsafe_set(i,i1);
            					}
            				}
            			}
            		}
            	}

In some scenarios this most likely isn't an issue, as haxe probably handles this, or if you're using -D no-compilation you can probably easy the strictness of these types of check.

However in my case I'm using -D no-compilation and don't have this kind of control. (compiling through unreal build tool)
This results in errors along the line of:
declaration of '_g' hides previous local declaration

It's also worth mentioning if I was writing something from scratch I'd simply avoid this pattern, however I'm porting a fairly large Haxe library that was originally intended for a different target and it has this issue all over the place.

My gut feeling is the compiler is most likely like this because it's a tricky problem to solve, but figured I'd ask here to see if anyone has any ideas

@peteshand
Copy link
Author

Actually, looks like there is a work around in my case.
For anyone that is interested, Unreal uses {Module}.build.cs files to config each module.. within this file the following property can be set to:
bEnableShadowVariableWarnings = false;

@Simn
Copy link
Member

Simn commented Nov 7, 2022

I don't really understand our renaming logic here and why that while makes any difference, but it looks like the C++ target has the wrong scope setting regardless.

@Simn
Copy link
Member

Simn commented Nov 7, 2022

Closed by 84e6ba4

@Simn Simn closed this as completed Nov 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants