Name shadows another variable error

Monte Goulding monte at sweattechnologies.com
Thu Nov 14 04:48:57 EST 2013


On 14/11/2013, at 7:35 PM, Malte Brill <revolution at derbrill.de> wrote:

> the easiest way for me to trigger the shadow Bug, is to change the scope of the variable from global to local
> 
> in a card script:
> 
> global tBoo
> 
> on openCard 
>  put "moo" into tBoo
> end openCard
> 
> hit apply, change script to
> 
> on openCard
>  local tBoo
>  put "moo" into tBoo
> end openCard
> 
> hit apply.

Well.. that would be because of this... which is kinda reasonable now that I think of it because it's explicit vars after all and the engine's not going to know that tBoo is no longer a global until after this script is parsed. So in this case compiling with explict vars off first would solve the issue. This is one reason I thought my suggestion the other day of having the IDE compile a script until there's no regular errors then turn on explicit vars to pick up those errors might resolve this issue a bit.

MCVariable *tmp;
for (tmp = MCglobals ; tmp != NULL ; tmp = tmp->getnext())
	if (tmp -> hasname(t_token_name))
		if (MCexplicitvariables)
		{
			MCperror->add(PE_LOCAL_SHADOW, sp);
			return PS_ERROR;
		}

Actually after having had a look I think it's the same issue for script locals. What happens is it goes looking for the locals and if it finds them it throws the shadowing error... but they aren't removed until the script is parsed... (not that I've found where they are removed)... anyway I'm pretty sure my plan of turning explicitvars on only once the script is fully parsed once will resolve the issue.

Here's the change at line 1486 of the template stack behavior for the script editor:
      local tOldPreserveVariables, tOldExplicitVariables 
      put the preserveVariables into tOldPreserveVariables
      put the explicitVariables into tOldExplicitVariables
      set the preserveVariables to sePrefGet("preserveVariables")
      
      # OK-2008-08-20 : All scripts end in return in the engine, we add the return here so that tScript
      # will match what the actual script gets set to. This ensures that we can store correct checksums for scripts.
      
      # OK-2008-10-16 : Bug 7199 - In fact, not all scripts end with a return, empty scripts should not have one.
      if the last char of tScript is not return and tScript is not empty then
         put return after tScript
      end if
      
      try
         set the script of pObject to tScript
         # MERG-2013-11-14: Compile without explicitVariables to avoid variable shadow errors
         if not the explicitVariables then
            set the explicitVariables to sePrefGet("explicitVariables")
            if not the explicitVariables then
               set the script of pObject to tScript
            end if
         end if
      catch tExecutionError
         if not pIgnoreErrors then
            send "addError execution, tExecutionError, pObject" to group "Errors" of me
            if sePrefGet("showerrors") then
               send "expandCurrentPane" to group "Panes" of me
            end if
         end if
      end try
      
      set the preserveVariables to tOldPreserveVariables
      set the explicitVariables to tOldExplicitVariables

I'm off to find a bug report about this and attach my findings

Cheers

--
Monte Goulding

M E R Goulding - software development services
mergExt - There's an external for that!



More information about the use-livecode mailing list