Browse thread
Re: [Caml-list] Bug in typing polymorphic variants found
-
Luc Maranget
- John Max Skaller
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | John Max Skaller <skaller@o...> |
| Subject: | Re: [Caml-list] Bug in typing polymorphic variants found |
Luc Maranget wrote:
>
>I did the same thing, and even ran felix under ocamldebug
>(another reason to use both bytecode and native compilation)
>
>1. I has to alter Flx_lex to compile
> (suppress a self reference to the Flx_lex module)
>
Funny. Must be CVS change. It compiles on my system.
[Yes, I see the self reference ..]
>
>2. By running the example (run), until it crashed
> going back (back) in execution a little, and looking at the
> call stack (backtrace), I found the loop :
>
>
>#52327 Pc : 242856 Flx_pretok char 6183
>#52328 Pc : 242856 Flx_pretok char 6183
>#52329 Pc : 242856 Flx_pretok char 6183
>#52330 Pc : 242856 Flx_pretok char 6183
>#52331 Pc : 242856 Flx_pretok char 6183
>#52332 Pc : 242856 Flx_pretok char 6183
>#52333 Pc : 242856 Flx_pretok char 6183
>
>etc...
>
>
>Apparently the loop is in module Flx_pretok :
>
>
>let pre_tokens_of_lexbuf buf state =
> let lex_it() = Flx_lex.pre_flx_lex buf state in
> let run = ref true in
> let rec get () =
> if !run
> then let t = lex_it () in
> match t with
> | [Flx_parse.ENDMARKER] ->
> run := false;
> [Flx_parse.ENDMARKER]
> | _ -> t @ get() <------- HERE is the recursive call
> else [Flx_parse.ENDMARKER]
> in get ()
>
The above code has been working
for 2 years. It hasn't been changed in 2 years. It is an infinite loop,
which is terminated by finding an ENDMARKER token in the code.
This token is generated by the lexer at end of file.
| eof { fun state -> [ENDMARKER] }
The parser creates a lot of polymorphic
variants. It also takes *ages* to compile
since a recent change I made: that change
contains several 3 step type coercions:
(a : t1 :> t2)
Perhaps the parser is overflowing some
table limit?
--
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners