Cherrypick from 2.9 (wrong way sorry) #4645

The alias file is never hidden, and is always public - even in the presence of a user given interface file. We experimented with making it private before but it never worked.

I need to get instance.exports.memory. Is there any way to get it in --js-library ?

Problem

Trying out that new rescript feature to generate an interface for an existing rescript file.

Reproduction

1. Ensure rescript 9.1.4 is active:

   > npx rescript -v
   9.1.4
   

2. Create a valid, working .res file like Example.res
3. Build the .res file
4. Invoke the dump command

   npx rescript dump ./lib/bs/src/Example-Project.cmi
   

Expected

Similar output when running bsc -i ./lib/bs/src/Example-Project.cmi, content that types the exports for a module that can be saved into a .resi file.

Actual

Get an error:

> npx rescript dump ./lib/bs/src/Example-Project.cmi

rescript: error: unknown target 'lib/bs/src/Example-Project.cmi'

Solution

After playing around did get it working with:

> npx rescript dump src/Example-Project.cmi

type example = int
type add5 = int => int

It was unclear that it expected a path suffix vs a real file, and not many hints from the CLI to figure out what it should be.

Constructor disambiguation can lead to confusing error messages, like:

module M = struct
  type t = A | B | C
  let get _ _ = A 
end

let () =
  match M.get () with
  | A | B | C -> ();;

Line 8, characters 4-5:
8 |   | A | B | C -> ();;
        ^
Error: Unbound constructor A

Here, the mistake was clearly missing an argument in the call to M.get, but the error message is complaining about an unbound constructor.

This PR adds a more specific error message for cases where disambiguation could not possibly work. For example, the above now gives:

Line 8, characters 4-5:
8 |   | A | B | C -> ();;
        ^
Error: This pattern should not be a constructor, the expected type is
       'a -> M.t

I'm okay with the change and the todo. Unrelated to the current problem, I was just wondering why we are not testing if the alias file is hidden by a user given interface for a wrapped library. But it is perhaps not installed at all, always public?

I'm not sure to which user we are talking about: user of the library, or the library developer.

See Commits and Changes for more details.

Created by <img src="https://prod.download/pull-18h-svg" valign="bottom"/> pull[bot]

Can you help keep this open source service alive? 💖 Please sponsor : )

See Commits and Changes for more details.

Created by <img src="https://prod.download/pull-18h-svg" valign="bottom"/> pull[bot]

Can you help keep this open source service alive? 💖 Please sponsor : )

I'll revert to the previous command line argument parsing.

Note that the diff is so huge because almost all the code has been restructured/rewritten; it is not just reformatted. But if you want I can try to split it up, this will be difficult though.

The output above is from the root of the rescript-compiler repository, not to compile something there but just to check if my build succeeded.

Is there a different way I should invoke the compiler I just compiled?

Multicore OCaml team has been working on ensuring that the stdlib remains backwards compatible and fast for sequential programs, and provides reasonable behaviour when used in parallel by multiple domains. We've written down the guarantees we expect to provide when stdlib is used in parallel. In particular, we propose not to provide thread-safety by default as this would slow down sequential programs. Hence, mutable data structures such as queues will not be thread-safe but remain type-safe. We would also like observationally pure interfaces to remain so even when used in parallel. We have made the internal mutable states in random, filename and hashtbl to be domain-local (PR#582).

Format

Similarly, format also has some global state, which causes issues in functions such as Format.printf when used in parallel, though they appear to be observationally pure. We would like to fix Format.printf such that they avoid unexpected behaviours -- such as raising Stdlib.Queue.Empty exception.

However, unlike the other modules, the global state is exposed by the format interface. In particular, the formatter type includes mutable state, and the interface exposes this mutable state in std_fomatter, err_formatter, str_formatter, but also std_buf. Since accessing domain-local state in Multicore OCaml needs to run code on the requesting domain, the current interface cannot be supported as is.

Proposal

The multicore team would prefer not to introduce a breaking change. Hence, our plan is to

1. Introduce domain-local format buffers for stdout, stderr and string formatters. This will fix Multicore OCaml Issue #563.
2. Update the documentation associated with values std_formatter, err_formatter, str_formatter and std_buf to indicate that they are the formatters and buffer used by the initial domain.
3. Provide additional functions to access the domain-local stdout, stderr and string formatters and the string buffer.

We request your comments on this proposal. We plan to adopt a similar strategy for other global states that may be exposed by stdlib.

Original bug ID: 7834 Reporter: @lpw25 Status: new Resolution: open Priority: normal Severity: minor Category: typing Monitored by: smuenzel-js @gasche

Bug description

The following code seems pretty reasonable:

  module type Q = sig
    type 'a t constraint 'a = [< `Empty | `Filled of _ ]
    module type S = sig 
      type 'a t constraint 'a = [< `Empty | `Filled of _ ] 
    end
    module M : S with type 'a t = 'a t
  end;;

but fails with the following error:

  Error: In this `with' constraint, the new definition of t
  does not match its original definition in the constrained signature:
  Type declarations do not match:                                                                                 
       type 'a t = 'a t constraint 'a = [< `Empty | `Filled of 'b & 'c & 'd ]
     is not included in
       type 'a t constraint 'a = [< `Empty | `Filled of 'b ]
     Their constraints differ.

I haven't dug into this issue properly, but I can see basically how it happens. I'm not really sure there is much we can do to fix it, I suspect it would require comparing the different &ed types, and that has been ruled out as a too much of a PITA before. Still I figured it was worth reporting anyway.

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

(Edit: this issue was originally written as a bug report, see the discussion below.)

Details can be found in depth in the README/code of this repo I created to reproduce the issue.

Essentially if I have the following code (pardon the syntax/formatting, I wrote this example in Reason and then outputted it as ocaml. this is all in the example repo in both ocaml and reason because I thought that might be a complicating factor, but it was not)

ExampleFramework.ml

;;Printexc.record_backtrace true
let numSlots = 100
let printBacktraceOnCall () =
  (Printexc.get_callstack numSlots) |> (Printexc.print_raw_backtrace stdout)
let run fn =
  match fn printBacktraceOnCall with
  | exception _ -> Printexc.print_backtrace stdout
  | _ -> ()

Examples.ml

let exceptionCase _ = raise Not_found
let callbackLastLineCase callback = (); callback ()
let unitLastLineCase callback = callback (); ()

ReproOcamlBugApp.ml

;;print_endline "\nexception behavior:\n"
;;ExampleFramework.run Examples.exceptionCase
;;print_endline "\nworks as expected:\n"
;;ExampleFramework.run Examples.unitLastLineCase
;;print_endline "\ndoes not have the Examples file in the stack trace:\n"
;;ExampleFramework.run Examples.callbackLastLineCase

I get the following output:

exception behavior:

Raised at file "ocaml-src/Examples.ml", line 1, characters 22-37
Called from file "ocaml-src/ExampleFramework.ml", line 6, characters 8-31

works as expected:

Raised by primitive operation at file "ocaml-src/ExampleFramework.ml", line 4, characters 2-35
Called from file "ocaml-src/Examples.ml", line 3, characters 32-43
Called from file "ocaml-src/ExampleFramework.ml", line 6, characters 8-31
Called from file "ocaml-src/ReproOcamlBugApp.ml", line 4, characters 2-48

does not have the Examples file in the stack trace:

Raised by primitive operation at file "ocaml-src/ExampleFramework.ml", line 4, characters 2-35
Called from file "ocaml-src/ExampleFramework.ml", line 6, characters 8-31
Called from file "ocaml-src/ReproOcamlBugApp.ml", line 6, characters 2-52

Essentially in the exception case and in the case with Printexc.get_callstack and a unit after the line that calls the callback I correctly get Examples.ml in the callstack, but without the unit Examples.ml is not in the callstack with Printexc.get_callstack and I expect it to be there (both logically and based on the exception behavior).

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

I feel like the real-world results are in, and forgetting/questioning -make-world is still a recurring problem for newcomers. I'm wondering if we should flip the priority and have bsb default to -make-world, and optionally expose a -self-only?

this is fixed. for normal users, they only need run rescript or rescript build -w