5.0.8 regression regarding $() in arithmetic for-loops

5.0.8 regression regarding $() in arithmetic for-loops

[Christian Neukirchen]

The following three forms are broken in zsh-5.0.8-0-gf0068ed (release)
and zsh-5.0.8-109-gb6a2f11:

% for (( $(true) ; ; )) do echo yes; done
zsh: parse error near `; '
zsh: parse error near `$(true) ; ; )) do ec...'
% for (( ; $(true) ; )) do echo yes; done 
zsh: parse error
zsh: parse error near `$(true) ; )) do echo...'
% for (( ; ; $(true) )) do echo yes; done 
zsh: parse error near `true'
zsh: parse error near `$(true) )) do echo y...'

On 5.0.7 they used to behave like infinite loops.

-- 
Christian Neukirchen  <chneukirchen@gmail.com>  http://chneukirchen.org

Re: 5.0.8 regression regarding $() in arithmetic for-loops

[Bart Schaefer]

On Jul 27,  3:48pm, Christian Neukirchen wrote:
}
} The following three forms are broken in zsh-5.0.8-0-gf0068ed (release)
} and zsh-5.0.8-109-gb6a2f11:
} 
} % for (( $(true) ; ; )) do echo yes; done
} zsh: parse error near `; '
} zsh: parse error near `$(true) ; ; )) do ec...'

Furthermore:

torch% for (( $(true) ; ; )) do echo yes; done
zsh: parse error near `; '
zsh: parse error near `$(true) ; ; )) do ec...'
torch% (( $(echo 1) ))                        
zsh: segmentation fault (core dumped)  Src/zsh

This happens after this example too:

} % for (( ; $(true) ; )) do echo yes; done 
} zsh: parse error
} zsh: parse error near `$(true) ; )) do echo...'

But not after this example:

} % for (( ; ; $(true) )) do echo yes; done 
} zsh: parse error near `true'
} zsh: parse error near `$(true) )) do echo y...'

I suspect we have a wordcode problem similar to the one with "case"
statements that was fixed earlier (although from a different parser
change).

#0  0x080ca7c1 in has_token (s=0x0) at ../../zsh-5.0/Src/utils.c:2030
#1  0x080a7115 in ecstrcode (s=0x0) at ../../zsh-5.0/Src/parse.c:390
#2  0x080a83f5 in par_cmd (cmplx=0xbff140ec, zsh_construct=0)

Re: 5.0.8 regression regarding $() in arithmetic for-loops

[Kamil Dudka]

On Monday 27 July 2015 08:34:49 Bart Schaefer wrote:
> This happens after this example too:
> 
> } % for (( ; $(true) ; )) do echo yes; done
> } zsh: parse error
> } zsh: parse error near `$(true) ; )) do echo...'
> 
> But not after this example:
> 
> } % for (( ; ; $(true) )) do echo yes; done
> } zsh: parse error near `true'
> } zsh: parse error near `$(true) )) do echo y...'
> 
> I suspect we have a wordcode problem similar to the one with "case"
> statements that was fixed earlier (although from a different parser
> change).
> 
> #0  0x080ca7c1 in has_token (s=0x0) at ../../zsh-5.0/Src/utils.c:2030
> #1  0x080a7115 in ecstrcode (s=0x0) at ../../zsh-5.0/Src/parse.c:390
> #2  0x080a83f5 in par_cmd (cmplx=0xbff140ec, zsh_construct=0)

It seems to be caused by the following commit:

http://sourceforge.net/p/zsh/code/ci/c0d01a6f

Kamil

PATCH Re: 5.0.8 regression regarding $() in arithmetic for-loops

[Bart Schaefer]

This turns out to be a recursive-descent parsing error, we weren't saving
enough state when entering command substitution from inside math parsing.

I'm not sure whether the "infor" stuff is actually necessary but it seemed
to make sense.  The real meat is dbparens = 0 when leaving math context.


diff --git a/Src/lex.c b/Src/lex.c
index b0cd963..70f3d14 100644
--- a/Src/lex.c
+++ b/Src/lex.c
@@ -1388,7 +1388,7 @@ dquote_parse(char endchar, int sub)
 {
     int pct = 0, brct = 0, bct = 0, intick = 0, err = 0;
     int c;
-    int math = endchar == ')' || endchar == ']';
+    int math = endchar == ')' || endchar == ']' || infor;
     int zlemath = math && zlemetacs > zlemetall + addedx - inbufct;
 
     while (((c = hgetc()) != endchar || bct ||
@@ -1995,8 +1995,10 @@ skipcomm(void)
 #else
     char *new_tokstr;
     int new_lexstop, new_lex_add_raw;
+    int save_infor = infor;
     struct lexbufstate new_lexbuf;
 
+    infor = 0;
     cmdpush(CS_CMDSUBST);
     SETPARBEGIN
     add(Inpar);
@@ -2065,6 +2067,7 @@ skipcomm(void)
      * the recursive parsing.
      */
     lexflags &= ~LEXFLAGS_ZLE;
+    dbparens = 0;	/* restored by zcontext_restore_partial() */
 
     if (!parse_event(OUTPAR) || tok != OUTPAR)
 	lexstop = 1;
@@ -2111,6 +2114,7 @@ skipcomm(void)
     if (!lexstop)
 	SETPAREND
     cmdpop();
+    infor = save_infor;
 
     return lexstop;
 #endif
diff --git a/Test/A01grammar.ztst b/Test/A01grammar.ztst
index 59f87fa..7eedfa6 100644
--- a/Test/A01grammar.ztst
+++ b/Test/A01grammar.ztst
@@ -182,6 +182,12 @@
 >1
 >2
 
+  for (( $(true); ; )); do break; done
+  for (( ; $(true); )); do break; done
+  for (( ; ; $(true) )); do break; done
+  for (( ; $((1)); )); do break; done
+0:regression test, nested cmdsubst in arithmetic `for' loop
+
   for keyvar valvar in key1 val1 key2 val2; do
      print key=$keyvar val=$valvar
   done

Re: PATCH Re: 5.0.8 regression regarding $() in arithmetic for-loops

[Kamil Dudka]

On Wednesday 29 July 2015 22:19:50 Bart Schaefer wrote:
> This turns out to be a recursive-descent parsing error, we weren't saving
> enough state when entering command substitution from inside math parsing.
> 
> I'm not sure whether the "infor" stuff is actually necessary but it seemed
> to make sense.  The real meat is dbparens = 0 when leaving math context.

This works for me, will apply it on Fedora.  Thanks for the patch!

Kamil