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

occasionally unhelpful behavior of toplevel when printing values #7751

Closed
vicuna opened this issue Mar 12, 2018 · 4 comments
Closed

occasionally unhelpful behavior of toplevel when printing values #7751

vicuna opened this issue Mar 12, 2018 · 4 comments
Assignees

Comments

@vicuna
Copy link

vicuna commented Mar 12, 2018

Original bug ID: 7751
Reporter: kosik
Assigned to: @garrigue
Status: confirmed (set by @garrigue on 2018-03-13T02:37:04Z)
Resolution: open
Priority: normal
Severity: minor
Version: 4.06.1
Category: toplevel
Related to: #7134
Monitored by: @nojb

Bug description

If I do this on the Ocaml toplevel:

  #use "topfind";;
  #require "compiler-libs.common";;
  Parse.implementation (Lexing.from_string "foo");;

what I see is this:

  - : Parsetree.structure =
  [{Parsetree.pstr_desc =
     Parsetree.Pstr_eval
      ({Parsetree.pexp_desc = Parsetree.Pexp_ident <abstr>; pexp_loc = <abstr>;
        pexp_attributes = []},
      []);
    pstr_loc = <abstr>}]

The problem (in my opinion) is that some of the values are printed as

  <abstr>

even if they are not abstract and the corresponding *.cmi files (which describes their structure) is available. For some reason, Ocaml toplevel chooses not to process them.

I find this behavior surprising (at least).
It certainly also is an undocumented behavior.

Related surprising behavior is that when I install printers for those values that are printed as <abstr>, those printers will not be used
(just because that Ocaml toplevel chooses (for an unknown reason) not to process relevant *.cmi files.

Interestingly, if I make some dummy calls of functions in some of the modules that Ocaml toplevel (temporarily) avoided to process, it processes them lazily and then the printing procedures behave in an expected manner.

Steps to reproduce

In Ocaml toplevel:

  #use "topfind";;
  #require "compiler-libs.common";;
  Parse.implementation (Lexing.from_string "foo");;

Additional information

https://sympa.inria.fr/sympa/arc/caml-list/2018-03/msg00033.html

@vicuna
Copy link
Author

vicuna commented Mar 12, 2018

Comment author: kosik

Sorry, the title should read:

"occasionally unhelpful behavior of Ocaml toplevel when printing values

@vicuna
Copy link
Author

vicuna commented Mar 13, 2018

Comment author: @garrigue

I observe the same behavior with

$ ocaml -I +compiler-libs ocamlcommon.cma
#  Parse.implementation (Lexing.from_string "foo");;

@vicuna
Copy link
Author

vicuna commented Mar 13, 2018

Comment author: @garrigue

Apparently the culprit is the fix of #7134, which blocked the loading of cmis.
A tentative fix is at: #1657

@yallop
Copy link
Member

yallop commented Apr 15, 2019

This appears to be fixed in 4.07.1:

# #use "topfind";;
[...]
# #require "compiler-libs.common";;
[...]
# Parse.implementation (Lexing.from_string "foo");;
  - : Parsetree.structure =
[{Parsetree.pstr_desc =
   Parsetree.Pstr_eval
    ({Parsetree.pexp_desc =
       Parsetree.Pexp_ident
        {Asttypes.txt = Longident.Lident "foo";
         loc =
          {Location.loc_start =
            {Lexing.pos_fname = ""; pos_lnum = 1; pos_bol = 0; pos_cnum = 0};
           loc_end =
            {Lexing.pos_fname = ""; pos_lnum = 1; pos_bol = 0; pos_cnum = 3};
           loc_ghost = false}};
      pexp_loc =
       {Location.loc_start =
         {Lexing.pos_fname = ""; pos_lnum = 1; pos_bol = 0; pos_cnum = 0};
        loc_end =
         {Lexing.pos_fname = ""; pos_lnum = 1; pos_bol = 0; pos_cnum = 3};
        loc_ghost = false};
      pexp_attributes = []},
    []);
  pstr_loc =
   {Location.loc_start =
     {Lexing.pos_fname = ""; pos_lnum = 1; pos_bol = 0; pos_cnum = 0};
    loc_end =
     {Lexing.pos_fname = ""; pos_lnum = 1; pos_bol = 0; pos_cnum = 3};
    loc_ghost = false}}]

@yallop yallop closed this as completed Apr 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants