[#42] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...>

32 messages 2002/05/25
[#43] Re: possible bug: stack dump with <<-String, #{...} and large loops — nobu.nokada@... 2002/05/26

Hi,

[#45] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...> 2002/05/26

>>>>> "n" == nobu nokada <nobu.nokada@softhome.net> writes:

[#46] Re: possible bug: stack dump with <<-String, #{...} and large loops — nobu.nokada@... 2002/05/26

Hi,

[#47] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...> 2002/05/26

>>>>> "n" == nobu nokada <nobu.nokada@softhome.net> writes:

[#48] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...> 2002/05/26

>>>>> "t" == ts <decoux@moulon.inra.fr> writes:

[#49] Re: possible bug: stack dump with <<-String, #{...} and large loops — nobu.nokada@... 2002/05/27

Hi,

[#50] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...> 2002/05/27

>>>>> "n" == nobu nokada <nobu.nokada@softhome.net> writes:

[#51] Re: possible bug: stack dump with <<-String, #{...} and large loops — nobu.nokada@... 2002/05/27

Hi,

[#52] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...> 2002/05/27

>>>>> "n" == nobu nokada <nobu.nokada@softhome.net> writes:

[#53] Re: possible bug: stack dump with <<-String, #{...} and large loops — nobu.nokada@... 2002/05/27

Hi,

[#54] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...> 2002/05/27

>>>>> "n" == nobu nokada <nobu.nokada@softhome.net> writes:

[#55] Re: possible bug: stack dump with <<-String, #{...} and large loops — nobu.nokada@... 2002/05/27

Hi,

[#56] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...> 2002/05/27

>>>>> "n" == nobu nokada <nobu.nokada@softhome.net> writes:

[#57] Re: possible bug: stack dump with <<-String, #{...} and large loops — nobu.nokada@... 2002/05/28

Hi,

[#65] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...> 2002/05/28

>>>>> "n" == nobu nokada <nobu.nokada@softhome.net> writes:

[#84] Re: possible bug: stack dump with <<-String, #{...} and large loops — nobu.nokada@... 2002/05/29

Hi,

[#92] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...> 2002/05/29

>>>>> "n" == nobu nokada <nobu.nokada@softhome.net> writes:

[#67] The warns-a-thon continues... — Sean Chittenden <sean@...>

I'm feeling left out in this race to clobber warnings!!! Attached are

19 messages 2002/05/28

[#104] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...>

>>>>> "n" == nobu nokada <nobu.nokada@softhome.net> writes:

29 messages 2002/05/30
[#105] Re: possible bug: stack dump with <<-String, #{...} and large loops — nobu.nokada@... 2002/05/30

Hi,

[#125] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...> 2002/06/04

>>>>> "n" == nobu nokada <nobu.nokada@softhome.net> writes:

[#126] Re: possible bug: stack dump with <<-String, #{...} and large loops — nobu.nokada@... 2002/06/04

Hi,

[#127] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...> 2002/06/04

>>>>> "n" == nobu nokada <nobu.nokada@softhome.net> writes:

[#130] Re: possible bug: stack dump with <<-String, #{...} and large loops — nobu.nokada@... 2002/06/04

Hi,

[#132] Re: possible bug: stack dump with <<-String, #{...} and large loops — nobu.nokada@... 2002/06/05

Hi,

[#134] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...> 2002/06/05

>>>>> "n" == nobu nokada <nobu.nokada@softhome.net> writes:

Re: possible bug: stack dump with <<-String, #{...} and large loops

From: nobu.nokada@...
Date: 2002-05-26 15:28:04 UTC
List: ruby-core #46
Hi,

At Sun, 26 May 2002 21:23:21 +0900,
ts wrote:
> n> Failed at rubicon/language/TestEval.rb.
> 
>  Well, expect have a special rb_compile_dstr() (to set a flag in this
>  case), I don't see (and I still don't like what it do)

Like this?


Index: node.h
===================================================================
RCS file: /cvs/ruby/src/ruby/node.h,v
retrieving revision 1.29
diff -u -2 -p -r1.29 node.h
--- node.h	2002/05/14 06:22:26	1.29
+++ node.h	2002/05/26 14:04:44
@@ -268,6 +268,6 @@ typedef struct RNode {
 #define NEW_GASGN(v,val) rb_node_newnode(NODE_GASGN,v,val,rb_global_entry(v))
 #define NEW_LASGN(v,val) rb_node_newnode(NODE_LASGN,v,val,local_cnt(v))
-#define NEW_DASGN(v,val) rb_node_newnode(NODE_DASGN,v,val,0);
-#define NEW_DASGN_CURR(v,val) rb_node_newnode(NODE_DASGN_CURR,v,val,0);
+#define NEW_DASGN(v,val) rb_node_newnode(NODE_DASGN,v,val,0)
+#define NEW_DASGN_CURR(v,val) rb_node_newnode(NODE_DASGN_CURR,v,val,0)
 #define NEW_IASGN(v,val) rb_node_newnode(NODE_IASGN,v,val,0)
 #define NEW_CDECL(v,val) rb_node_newnode(NODE_CDECL,v,val,0)
@@ -339,4 +339,5 @@ typedef struct RNode {
 
 NODE *rb_compile_cstr _((const char*, const char*, int, int));
+NODE *rb_compile_dstr _((const char*, VALUE, int));
 NODE *rb_compile_string _((const char*, VALUE, int));
 NODE *rb_compile_file _((const char*, VALUE, int));
Index: eval.c
===================================================================
RCS file: /cvs/ruby/src/ruby/eval.c,v
retrieving revision 1.295
diff -u -2 -p -r1.295 eval.c
--- eval.c	2002/05/21 05:39:18	1.295
+++ eval.c	2002/05/26 14:00:14
@@ -3074,7 +3074,8 @@ rb_eval(self, n)
 			ruby_sourceline = nd_line(node);
 			ruby_in_eval++;
-			list->nd_head = compile(list->nd_head->nd_lit,
-						ruby_sourcefile,
-						ruby_sourceline);
+			ruby_nerrs = 0;
+			list->nd_head = rb_compile_dstr(ruby_sourcefile,
+							list->nd_head->nd_lit,
+							ruby_sourceline);
 			ruby_eval_tree = 0;
 			ruby_in_eval--;
Index: parse.y
===================================================================
RCS file: /cvs/ruby/src/ruby/parse.y,v
retrieving revision 1.172
diff -u -2 -p -r1.172 parse.y
--- parse.y	2002/05/22 09:37:45	1.172
+++ parse.y	2002/05/26 15:20:04
@@ -2249,5 +2249,5 @@ rb_compile_string(f, s, line)
     lex_pbeg = lex_p = lex_pend = 0;
     ruby_sourceline = line - 1;
-    compile_for_eval = ruby_in_eval;
+    compile_for_eval = ruby_in_eval != 0;
 
     return yycompile(f, line);
@@ -2263,4 +2263,20 @@ rb_compile_cstr(f, s, len, line)
 
 NODE*
+rb_compile_dstr(f, s, line)
+    const char *f;
+    VALUE s;
+    int line;
+{
+    lex_gets = lex_get_str;
+    lex_gets_ptr = 0;
+    lex_input = s;
+    lex_pbeg = lex_p = lex_pend = 0;
+    ruby_sourceline = line - 1;
+    compile_for_eval = 2;
+
+    return yycompile(f, line);
+}
+
+NODE*
 rb_compile_file(f, file, start)
     const char *f;
@@ -5102,6 +5118,12 @@ top_local_init()
     if (ruby_dyna_vars)
 	lvtbl->dlev = 1;
-    else
+    else {
 	lvtbl->dlev = 0;
+	if (compile_for_eval > 1) {
+	    dyna_push();
+	    ruby_eval_tree = block_append(ruby_eval_tree,
+					  NEW_DASGN(0, NEW_LIT(0)));
+	}
+    }
 }
 


-- 
Nobu Nakada

In This Thread