Allow linking empty .cmxa files on MSVC
(cherry picked from commit 7b6098a)

An analysis of the code should convince yourself that this function is
not needed and that its erroring paths are dead code.

The reasoning is the following: all the uses of [object_file_name] in
asmlink.ml are performed on [obj_infos] which went through [read_file]
before. The latter does exactly the same file name lookup and erroring
treatement, except not in a stringly manner like [object_file_name]
does.

This first commit removes use of the function in [scan_file] which was
introduced by PR ocaml#9011. The result of [object_file_name] here is equal
to [file_name] (follow [read_file]).

This function derives the same information as [object_file_name]
except it does it on the [file] datatype returned by [read_file].
Note that all the erroring code paths of [object_file_name] have been
handled by the [read_file] which derived the [file] value.

We integrate the logic added by PR ocaml#9011 for empty cmxa here.

This commit does the following four things (it's difficult
to them in separate commits that compile).

1) It removes the [read_file] from [scan_file]. Reading the files is
   done seperately before returning an [obj_infos] list of [file]
   values. This turns [scan_file] into a function that operates on
   values of type [file].

2) In [scan_file] it removes the separate list of [obj_files]
   introduced by ocaml#9011. We can derive the same list using the function
   [object_file_name_of_file] introduced in the previous commit on the
   list of [obj_infos]. Effectively we bring back [scan_file] to the
   state before ocaml#9011 modulo the [read_file] removal.

3) We derive the list of [obj_files] directly from the
   [obj_infos] list via [object_file_name_of_file]. Note that
   the logic introduced by ocaml#9011 is preserved by virtue of
   [object_file_name_of_file]'s optional result.

4) Deletes [object_file_name] which is no longer used.

An analysis of the code should convince yourself that the
[object_file_name] function is not needed and that its erroring paths
are dead code.

The reasoning is the following: all the uses of [object_file_name] in
asmlink.ml are performed on [obj_name]s which went through [read_file]
before. The latter does exactly the same file name lookup and erroring
treatement, except not in a stringly manner like [object_file_name]
does.

This new function derives the same information as [object_file_name]
except it does it on the [file] datatype returned by [read_file].
Note that all the erroring code paths of [object_file_name] have been
handled by the [read_file] which derived the [file] value.

We integrate the logic added by PR ocaml#9011 for empty cmxa here.

This commit does the following four things (it's difficult
to them in separate commits that compile).

1) It removes the [read_file] from [scan_file]. Reading the files is
   done seperately before returning an [obj_infos] list of [file]
   values. This turns [scan_file] into a function that operates on
   values of type [file].

2) In [scan_file] it removes the separate list of [obj_files]
   introduced by ocaml#9011. We can derive the same list using the function
   [object_file_name_of_file] introduced in the previous commit on the
   list of [obj_infos]. Effectively we bring back [scan_file] to the
   state before ocaml#9011 modulo the [read_file] removal.

3) We derive the list of [obj_files] directly from the
   [obj_infos] list via [object_file_name_of_file]. Note that
   the logic introduced by ocaml#9011 is preserved by virtue of
   [object_file_name_of_file]'s optional result.

4) Deletes [object_file_name] which is no longer used.

An analysis of the code should convince yourself that the
[object_file_name] function is not needed and that its erroring paths
are dead code.

The reasoning is the following: all the uses of [object_file_name] in
asmlink.ml are performed on [obj_name]s which went through [read_file]
before. The latter does exactly the same file name lookup and erroring
treatement, except not in a stringly manner like [object_file_name]
does.

This new function derives the same information as [object_file_name]
except it does it on the [file] datatype returned by [read_file].
Note that all the erroring code paths of [object_file_name] have been
handled by the [read_file] which derived the [file] value.

We integrate the logic added by PR ocaml#9011 for empty cmxa here.

This commit does the following four things (it's difficult
to them in separate commits that compile).

1) It removes the [read_file] from [scan_file]. Reading the files is
   done seperately before returning an [obj_infos] list of [file]
   values. This turns [scan_file] into a function that operates on
   values of type [file].

2) In [scan_file] it removes the separate list of [obj_files]
   introduced by ocaml#9011. We can derive the same list using the function
   [object_file_name_of_file] introduced in the previous commit on the
   list of [obj_infos]. Effectively we bring back [scan_file] to the
   state before ocaml#9011 modulo the [read_file] removal.

3) We derive the list of [obj_files] directly from the
   [obj_infos] list via [object_file_name_of_file]. Note that
   the logic introduced by ocaml#9011 is preserved by virtue of
   [object_file_name_of_file]'s optional result.

4) Deletes [object_file_name] which is no longer used.

…rt upstream PR#9943) (ocaml#557)

* Asmlink.object_file_name removal: add object_file_name_of_file

An analysis of the code should convince yourself that the
[object_file_name] function is not needed and that its erroring paths
are dead code.

The reasoning is the following: all the uses of [object_file_name] in
asmlink.ml are performed on [obj_name]s which went through [read_file]
before. The latter does exactly the same file name lookup and erroring
treatement, except not in a stringly manner like [object_file_name]
does.

This new function derives the same information as [object_file_name]
except it does it on the [file] datatype returned by [read_file].
Note that all the erroring code paths of [object_file_name] have been
handled by the [read_file] which derived the [file] value.

We integrate the logic added by PR ocaml#9011 for empty cmxa here.

* Asmlink.object_file_name removal: remove.

This commit does the following four things (it's difficult
to them in separate commits that compile).

1) It removes the [read_file] from [scan_file]. Reading the files is
   done seperately before returning an [obj_infos] list of [file]
   values. This turns [scan_file] into a function that operates on
   values of type [file].

2) In [scan_file] it removes the separate list of [obj_files]
   introduced by ocaml#9011. We can derive the same list using the function
   [object_file_name_of_file] introduced in the previous commit on the
   list of [obj_infos]. Effectively we bring back [scan_file] to the
   state before ocaml#9011 modulo the [read_file] removal.

3) We derive the list of [obj_files] directly from the
   [obj_infos] list via [object_file_name_of_file]. Note that
   the logic introduced by ocaml#9011 is preserved by virtue of
   [object_file_name_of_file]'s optional result.

4) Deletes [object_file_name] which is no longer used.

Co-authored-by: Daniel Bünzli <[email protected]>

…s) in asmlink (port upstream PR#9943) (ocaml#557)

* Asmlink.object_file_name removal: add object_file_name_of_file

An analysis of the code should convince yourself that the
[object_file_name] function is not needed and that its erroring paths
are dead code.

The reasoning is the following: all the uses of [object_file_name] in
asmlink.ml are performed on [obj_name]s which went through [read_file]
before. The latter does exactly the same file name lookup and erroring
treatement, except not in a stringly manner like [object_file_name]
does.

This new function derives the same information as [object_file_name]
except it does it on the [file] datatype returned by [read_file].
Note that all the erroring code paths of [object_file_name] have been
handled by the [read_file] which derived the [file] value.

We integrate the logic added by PR ocaml#9011 for empty cmxa here.

* Asmlink.object_file_name removal: remove.

This commit does the following four things (it's difficult
to them in separate commits that compile).

1) It removes the [read_file] from [scan_file]. Reading the files is
   done seperately before returning an [obj_infos] list of [file]
   values. This turns [scan_file] into a function that operates on
   values of type [file].

2) In [scan_file] it removes the separate list of [obj_files]
   introduced by ocaml#9011. We can derive the same list using the function
   [object_file_name_of_file] introduced in the previous commit on the
   list of [obj_infos]. Effectively we bring back [scan_file] to the
   state before ocaml#9011 modulo the [read_file] removal.

3) We derive the list of [obj_files] directly from the
   [obj_infos] list via [object_file_name_of_file]. Note that
   the logic introduced by ocaml#9011 is preserved by virtue of
   [object_file_name_of_file]'s optional result.

4) Deletes [object_file_name] which is no longer used.

Co-authored-by: Daniel Bünzli <[email protected]>