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

Calling Grammar.Entry.parse from inside a grammar action results in wrong location (e.g. INCLUDE in pa_macro) #3798

Closed
vicuna opened this issue Sep 27, 2005 · 3 comments
Labels

Comments

@vicuna
Copy link

vicuna commented Sep 27, 2005

Original bug ID: 3798
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: Aleksey Nogin
Version: 3.08.4
OS: Fedora Core 3
Submission from: dsl57-22.uninet.ee (194.204.57.22)

If a grammar action cals Grammar.Entry.parse (on an unrelated stream), then the
locations in the outer ("original") parsing are wrong after that.

A concrete example - when using pa_macro on a file that contains an "INCLUDE"
directive (which causes the included file to be parsed at that point), all
locations for the expressions after the INCLUDE directive in the original file
are off by the "# of lines in the INCLUDE file).

P.S. Most likely, this is another instance of the problem originally reported in
#2954.

P.P.S. I tried looking at the code. I believe that the problem comes from the
following:

  1. pa_o (same for pa_r) calls Plexer.make_lexer once when it's initialized
    (and never does it again).

  2. Plexer.make_lexer calles Plexer.func

  3. Plexer.func creates bol_pos and lnum ref cells that are shared among all the
    future invocations of this lexer and are never reset!

@vicuna
Copy link
Author

vicuna commented Sep 27, 2005

Comment author: administrator

Here is a patch/workaround that fixes the pa_macro instance of #3798.
IMHO the proper way of solving #2954/3407/3798 would involve getting
rid of these "shared" bol/lnum refs, but this provides a workaround
until the time that this might be fixed properly. I am guessing that a
similar workaround can be used by anybody who experiences #2954/3407.

This patch also ensures that the INCLUDE files will be closed (pa_macro
was forgetting to do that).

--
Aleksey Nogin

Home Page: http://nogin.org/
E-Mail: nogin@cs.caltech.edu (office), aleksey@nogin.org (personal)
Office: Moore 04, tel: (626) 395-2200


--- pa_macro.ml.orig 2004-07-02 02:37:16.000000000 -0700
+++ pa_macro.ml 2005-09-27 05:01:46.449242576 -0700
@@ -239,12 +239,29 @@
try (List.find (dir_ok file) (include_dirs.val @ ["./"])) ^ file
with [ Not_found -> file ]
in

  • let st = Stream.of_channel (open_in file) in
  • let ch = open_in file in
  • let st = Stream.of_channel ch in
    let old_input = Pcaml.input_file.val in
  • let (bol_ref, lnum_ref, name_ref) = Pcaml.position.val in
  • let (old_bol, old_lnum, old_name) = (bol_ref.val, lnum_ref.val, name_ref.val) in
  • let restore () =
  •  do {
    
  •    close_in ch;
    
  •    bol_ref.val := old_bol;
    
  •    lnum_ref.val := old_lnum;
    
  •    name_ref.val := old_name;
    
  •    Pcaml.input_file.val := old_input;
    
  •  }
    
  • in
    do {
  •  bol_ref.val := 0;
    
  •  lnum_ref.val := 1;
    
  •  name_ref.val := file;
     Pcaml.input_file.val := file;
    
  •  let items = Grammar.Entry.parse smlist st in
    
  •  do { Pcaml.input_file.val := old_input; items } }
    
  •  try
    
  •    let items = Grammar.Entry.parse smlist st in
    
  •    do { restore (); items }
    
  •  with [ exn -> do { restore (); raise exn } ] }
    

;

value rec execute_macro = fun



@vicuna
Copy link
Author

vicuna commented Oct 12, 2005

Comment author: administrator

Camlp4 issue.

@vicuna
Copy link
Author

vicuna commented Oct 21, 2005

Comment author: administrator

Here is a patch/workaround that fixes the pa_macro instance of #3798.

Hi Aleksey,

I've integrated your patch in the CVS.

Regards,

-- Michel

@vicuna vicuna closed this as completed Oct 21, 2005
@vicuna vicuna added the bug label Mar 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant