This PR implements functions for parsing of argument files. Do you plan to eventually add commits that combine this with the new Expand support to actually provide -args/args0 arguments to the compiler tools, or would that be out of the scope of the current PR?

I added the functions to the compiler command line arguments.

For the other tools: I will have a look but as @diml noted ocamldebug for example needs special care.

I added ocamldep to the list of supported tools. I also added a simple wrapper around parse_and_expand_argv_dynamic that also prints error/help messages to Arg. In order to avoid the problems with current and the changed array the function does not modify Arg.current is not modified.

For the other tools: I will have a look but as @diml noted ocamldebug for example needs special care.

I did not mean to push hard for supporting all tools, but since you asked about scope (in #748 (comment)) I wanted to give a positive answer. I'd be happy with a partial implementation anyway.

List of missing tools/programs:

• ocaml
• ocamldebug
• ocamlyacc
• ocamlex
• ocamldoc
• cvt_emit
• cmpbyt
• ocamlmklib
• ocamlmktop
• stripdebug

For stripdebug, cvt_emit, cmpbyt and ocamlyacc, ocamllex it does not make sense to add it since they expect a constant number of options.

ocamlmktop only passes the commands on.

ocamldebug, ocaml, ocamldoc and ocamlmklib all have either hand written parse functions or require some preprocessing of the arguments and I'm unsure if it works for them without problem.

I did not mean to push hard for supporting all tools, but since you asked about scope (in #748 (comment)) I wanted to give a positive answer. I'd be happy with a partial implementation anyway.

No problem, most of them are pretty straightforward.

I think that it would be nice to have support in ocaml and ocamlnat as well (you may have noticed that I mistakenly advertised it to Coq developers; I thought that the functorized argument-parsing machinery would provide the feature for the toplevels as well). It could be useful for the Coq use-case, as it allows as a debugging technique to "Drop" to the OCaml toplevel.

(Command-line is in the files toplevel/topmain.ml (for ocaml) and toplevel/opttopmain.ml (for ocamlnat). The native toplevel is not officially supported but it's on the path to redemption these days, so it's nice to keep it in synch.)

I will have a look at ocaml and ocamlnat.

It seems like it is not possible without some unsafe operations:

let override_sys_argv args =
  let len = Array.length args in
  if Array.length Sys.argv < len then invalid_arg "Toploop.override_sys_argv";
  Array.blit args 0 Sys.argv 0 len;
  Obj.truncate (Obj.repr Sys.argv) len;
  Arg.current := 0

The toplevel uses a horrible hack so that the first argument is the name of the executed file instead of the toplevel binary (I suppose). But how does this prevent handling Expand nodes in the argument array after this hack has been applied? I don't understand why there is a conflict here.

override_sys_argv actually copies the rest of the un-parsed arguments into Sys.argv and then truncates Sys.argv. However Expand may increase the array beyond the length of Sys.argv and the copy would only work if the size is increased instead of making it smaller.

So if I understand correctly, the toplevel parses the provided argument list, then it stops on the first anonymous argument that is a source file (.ml extension), and considers that the remaining arguments are to be processed by the script itself upon execution, so it rewrites Sys.argv in place to have just the remaining argument as the control is passed to the script.

As it rewrites the arguments, it checks that the new argument-list is smaller than the previous one (as it is supposed to be a suffix of it). This could fail in general if one of the Expand node would generate a source file argument. (Note that if the Expand nodes don't generate source files argument, this would succeed, as the suffix would remain the same).

I'm confident there is a reasonable solution (for example we could just disable the size check that is certainly there for debugging), but it also seems to require a bit more work than I hoped. Would you agree with merging the current PR, and eventually support the toplevel in a following PR?

(I'm not implying that you personally have to do the toplevel-related work. If I have time I could try to implement it myself. Let us know what you want to do.)

That is fine with me.

Could you add a Changes entry? Suggestion:

### Compiler user-interface and warnings:

[...]

- MPR#7050, GPR#748 GPR#843: new `-arg/-arg0 <file>` parameters to provide
  extra command-line arguments in a file -- see documentation.
  User programs may implement similar options
  using the new `Arg.Expand` constructor.
  (Bernhard Schommer, review by Jérémie Dimino, Gabriel Scherer
   and Damien Doligez, discussion with Alain Frisch and Xavier Leroy,
   feature request from the Coq team)

Thanks a lot for your hard work! Do you plan to look at the toplevel?

I will have a look at it. Basically it seems that instead of truncate one needs some kind of adjust primitive. When I find a solution I will open a new PR.

(I now understand that relaxing the check is not enough as truncate actually requires a smaller value. Maybe the toplevel could just forbid source script names from within the return of Expand?)

@alainfrisch rightly pointed out that this feature was not documented (it's not in the manual or in the compiler manpages). I am planning on opening a Mantis ticket to track that need (tomorrow). @bschommer, would you be willing to send a patch for that?