Remove unused domain functions

…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]>

fe8a98b flambda-backend: Save Mach as Cfg after Selection (ocaml#624)
2b205d8 flambda-backend: Clean up algorithms (ocaml#611)
524f0b4 flambda-backend: Initial refactoring of To_cmm (ocaml#619)
0bf75de flambda-backend: Refactor and correct the "is pure" and "can raise" (port upstream PR#10354 and PR#10387) (ocaml#555)
d234bfd flambda-backend: Cpp mangling is now a configuration option (ocaml#614)
20fc614 flambda-backend: Check that stack frames are not too large (ocaml#10085) (ocaml#561)
5fc2e95 flambda-backend: Allow CSE of immutable loads across stores (port upstream PR#9562) (ocaml#562)
2a650de flambda-backend: Backport commit fc95347 from trunk (ocaml#584)
31651b8 flambda-backend: Improved ARM64 code generation (port upstream PR#9937) (ocaml#556)
f0b6d68 flambda-backend: Simplify processing and remove dead code (error paths) in asmlink (port upstream PR#9943) (ocaml#557)
90c6746 flambda-backend: Improve code-generation for inlined comparisons (port upstream PR#10228) (ocaml#563)

git-subtree-dir: ocaml
git-subtree-split: fe8a98b

…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]>