refactor: use the proposed implementation for redirects

bin/describe/describe_external_lib_deps.ml

@@ -68,13 +68,17 @@ type dep =
 
 let is_external db name =
   let open Memo.O in
-  let+ lib = Dune_rules.Lib.DB.find_even_when_hidden db name in
-  match lib with
-  | None -> true
-  | Some t ->
-    (match Dune_rules.Lib_info.status (Dune_rules.Lib.info t) with
-     | Installed_private | Public _ | Private _ -> false
-     | Installed -> true)
+  Dune_rules.Lib.DB.find_stanza_id db name
+  >>= function
+  | None -> Memo.return true
+  | Some library_id ->
+    let+ lib = Dune_rules.Lib.DB.find_even_when_hidden db library_id in
+    (match lib with
+     | None -> true
+     | Some t ->
+       (match Dune_rules.Lib_info.status (Dune_rules.Lib.info t) with
+        | Installed_private | Public _ | Private _ -> false
+        | Installed -> true))
 ;;
 
 let resolve_lib db name kind =

bin/describe/describe_workspace.ml

@@ -337,7 +337,9 @@ module Crawl = struct
     | { with_deps = false; _ } ->
       Action_builder.return { Ocaml.Ml_kind.Dict.intf = []; impl = [] }
     | { with_deps = true; _ } ->
-      let deps = Dune_rules.Dep_rules.immediate_deps_of unit modules obj_dir in
+      let deps ml_kind =
+        Dune_rules.Dep_rules.immediate_deps_of unit modules ~obj_dir ~ml_kind
+      in
       let open Action_builder.O in
       let+ intf, impl = Action_builder.both (deps Intf) (deps Impl) in
       { Ocaml.Ml_kind.Dict.intf; impl }
@@ -447,9 +449,10 @@ module Crawl = struct
         | true ->
           (* XXX why do we have a second object directory? *)
           let* modules_, obj_dir_ =
+            let library_id = Lib.library_id lib in
             Dir_contents.get sctx ~dir:(Path.as_in_build_dir_exn src_dir)
             >>= Dir_contents.ocaml
-            >>| Ml_sources.modules_and_obj_dir ~for_:(Library name)
+            >>| Ml_sources.modules_and_obj_dir ~for_:(Library library_id)
           in
           let* pp_map =
             let+ version =

doc/advanced/custom-cmxs.rst

@@ -12,7 +12,7 @@ For the specific cases where this extra flexibility is needed, one can use
 not associated to any library.
 
 Below is an example where we build ``my.cmxs`` containing ``foo.cmxa`` and
-``d.cmx``. Note how we use a :doc:`/reference/files/dune/library` stanza to set
+``d.cmx``. Note how we use a :doc:`/reference/dune/library` stanza to set
 up the compilation of ``d.cmx``.
 
 .. code:: dune

doc/advanced/package-version.rst

@@ -5,7 +5,7 @@ Package Version
    - reference: environment - packages
 
 Dune determines a package's version by looking at the ``version`` field in the
-:doc:`/reference/files/dune-project/package`. If the version field isn't set,
+:doc:`/reference/dune-project/package`. If the version field isn't set,
 it looks at the toplevel ``version`` field in the ``dune-project`` field. If
 neither are set, Dune assumes that we are in development mode and reads the
 version from the VCS, if any. The way it obtains the version from the VCS is

doc/changes/10286.md

@@ -0,0 +1,3 @@
+- melange: fix a bug that would cause stale `import` paths to be emitted when
+  moving source files within `(include_subdirs ..)`
+  (#10286, fixes #9190, @anmonteiro)

doc/concepts/package-spec.rst

@@ -144,4 +144,4 @@ Other Files
 ^^^^^^^^^^^
 
 For all other kinds of elements, you must attach them manually via
-an :doc:`/reference/files/dune/install` stanza.
+an :doc:`/reference/dune/install` stanza.

doc/concepts/variables.rst

@@ -88,7 +88,7 @@ In addition, ``(action ...)`` fields support the following special variables:
 - ``exe:<path>`` is the same as ``<path>``, except when cross-compiling, in
   which case it will expand to ``<path>`` from the host build context.
 - ``bin:<program>`` expands ``<path>`` to ``program``. If ``program``
-  is installed by a workspace package (see :doc:`/reference/files/dune/install`
+  is installed by a workspace package (see :doc:`/reference/dune/install`
   stanzas), the locally built binary will be used, otherwise it will be
   searched in the ``<path>`` of the current build context. Note that ``(run
   %{bin:program} ...)`` and ``(run program ...)`` behave in the same way.
@@ -172,7 +172,7 @@ creates a cycle.
 Some cycles might be more complex. In any case, when you see such an
 error, the easiest thing to do is move the file that's being read
 to a different directory, preferably a standalone one. You can use the
-:doc:`/reference/files/dune/subdir` stanza to keep the logic self-contained in
+:doc:`/reference/dune/subdir` stanza to keep the logic self-contained in
 the same ``dune`` file:
 
 .. code:: dune

doc/conf.py

@@ -41,6 +41,7 @@
 # ones.
 extensions = [
     'sphinx_copybutton',
+    'sphinx_design',
 ]
 
 # Add any paths that contain templates here, relative to this directory.

doc/coq.rst

@@ -26,29 +26,29 @@ names share a common prefix. The module names reflect the directory hierarchy.
 Coq theories may be defined using :ref:`coq.theory<coq-theory>` stanzas, or be
 auto-detected by Dune by inspecting Coq's install directories.
 
-A *Coq plugin* is an OCaml :doc:`/reference/files/dune/library` that Coq can
+A *Coq plugin* is an OCaml :doc:`/reference/dune/library` that Coq can
 load dynamically at runtime. Plugins are typically linked with the Coq OCaml
 API.
 
 Since Coq 8.16, plugins need to be "public" libraries in Dune's terminology,
 that is to say, they must declare a ``public_name`` field.
 
 A *Coq project* is an informal term for a
-:doc:`/reference/files/dune-project/index` containing a collection of Coq
+:doc:`/reference/dune-project/index` containing a collection of Coq
 theories and plugins.
 
 The ``.v`` files of a theory need not be present as source files. They may also
 be Dune targets of other rules.
 
 To enable Coq support in a Dune project, specify the :ref:`Coq language
-version<coq-lang>` in the :doc:`/reference/files/dune-project/index` file. For
+version<coq-lang>` in the :doc:`/reference/dune-project/index` file. For
 example, adding
 
 .. code:: dune
 
     (using coq 0.8)
 
-to a :doc:`/reference/files/dune-project/index` file enables using the
+to a :doc:`/reference/dune-project/index` file enables using the
 ``coq.theory`` stanza and other ``coq.*`` stanzas. See the :ref:`Dune Coq
 language<coq-lang>` section for more details.
 
@@ -58,7 +58,7 @@ coq.theory
 ----------
 
 The Coq theory stanza is very similar in form to the OCaml
-:doc:`/reference/files/dune/library` stanza:
+:doc:`/reference/dune/library` stanza:
 
 .. code:: dune
 
@@ -115,7 +115,7 @@ The semantics of the fields are:
 
 - ``<coq_flags>`` are passed to ``coqc`` as command-line options. ``:standard``
   is taken from the value set in the ``(coq (flags <flags>))`` field in ``env``
-  profile. See :doc:`/reference/files/dune/env` for more information.
+  profile. See :doc:`/reference/dune/env` for more information.
 
 - ``<coqdoc_flags>`` are extra user-configurable flags passed to ``coqdoc``. The
   default value for ``:standard`` is ``--toc``. The ``--html`` or ``--latex``
@@ -175,8 +175,8 @@ Coq Documentation
 Given a :ref:`coq-theory` stanza with ``name A``, Dune will produce two
 *directory targets*, ``A.html/`` and ``A.tex/``. HTML or LaTeX documentation for
 a Coq theory may then be built by running ``dune build A.html`` or ``dune build
-A.tex``, respectively (if the :doc:`dune file </reference/files/dune/index>`
-for the theory is the current directory).
+A.tex``, respectively (if the :doc:`dune file </reference/dune/index>` for the
+theory is the current directory).
 
 There are also two aliases ``@doc`` and ``@doc-latex`` that will respectively
 build the HTML or LaTeX documentation when called. These will determine whether
@@ -198,7 +198,7 @@ If you add:
 
     (include_subdirs qualified)
 
-to a :doc:`/reference/files/dune/index` file, Dune considers all the modules in
+to a :doc:`/reference/dune/index` file, Dune considers all the modules in
 the directory and its subdirectories, adding a prefix to the module name in the
 usual Coq style for subdirectories. For example, file ``A/b/C.v`` becomes the
 module ``A.b.C``.
@@ -222,9 +222,9 @@ Dune organises it's knowledge about Coq theories in 3 databases:
 
   The public theory database allows theories to depend on theories that are in
   a different scope. Thus, you can depend on theories belonging to another
-  :doc:`/reference/files/dune-project/index` as long as they share a common
-  scope under another :doc:`/reference/files/dune-project/index` file or a
-  :doc:`/reference/files/dune-workspace/index` file.
+  :doc:`/reference/dune-project/index` as long as they share a common
+  scope under another :doc:`/reference/dune-project/index` file or a
+  :doc:`/reference/dune-workspace/index` file.
 
   Doing so is usually as simple as placing a Coq project within the scope of
   another. This process is termed *composition*. See the :ref:`interproject
@@ -276,10 +276,10 @@ Public and Private Theories
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 A *public theory* is a :ref:`coq-theory` stanza that is visible outside the
-scope of a :doc:`/reference/files/dune-project/index` file.
+scope of a :doc:`/reference/dune-project/index` file.
 
 A *private theory* is a :ref:`coq-theory` stanza that is limited to the scope
-of the :doc:`/reference/files/dune-project/index` file it is in.
+of the :doc:`/reference/dune-project/index` file it is in.
 
 A private theory may depend on both private and public theories; however, a
 public theory may only depend on other public theories.
@@ -321,7 +321,7 @@ Coq Language Version
 ~~~~~~~~~~~~~~~~~~~~
 
 The Coq lang can be modified by adding the following to a
-:doc:`/reference/files/dune-project/index` file:
+:doc:`/reference/dune-project/index` file:
 
 .. code:: dune
 
@@ -388,7 +388,7 @@ as any other sources.
 
 Note that the sources are extracted to the directory where the ``prelude`` file
 lives. Thus the common placement for the ``OCaml`` stanzas is in the same
-:doc:`/reference/files/dune/index` file.
+:doc:`/reference/dune/index` file.
 
 **Warning**: using Coq's ``Cd`` command to work around problems with the output
 directory is not allowed when using extraction from Dune. Moreover the ``Cd``
@@ -424,15 +424,15 @@ Simple Project
 ~~~~~~~~~~~~~~
 
 Let us start with a simple project. First, make sure we have a
-:doc:`/reference/files/dune-project/index` file with a :ref:`Coq
+:doc:`/reference/dune-project/index` file with a :ref:`Coq
 lang<coq-lang>` stanza present:
 
 .. code:: dune
 
   (lang dune 3.15)
   (using coq 0.8)
 
-Next we need a :doc:`/reference/files/dune/index` file with a :ref:`coq-theory`
+Next we need a :doc:`/reference/dune/index` file with a :ref:`coq-theory`
 stanza:
 
 .. code:: dune
@@ -485,7 +485,7 @@ Here is an example of a more complicated setup:
   │   └── dune
   └── dune-project
 
-Here are the :doc:`/reference/files/dune/index` files:
+Here are the :doc:`/reference/dune/index` files:
 
 .. code:: dune
 
@@ -501,7 +501,7 @@ Here are the :doc:`/reference/files/dune/index` files:
 
 Notice the ``theories`` field in ``B`` allows one :ref:`coq-theory` to depend on
 another. Another thing to note is the inclusion of the
-:doc:`/reference/files/dune/include_subdirs` stanza. This allows our theory to
+:doc:`/reference/dune/include_subdirs` stanza. This allows our theory to
 have :ref:`multiple subdirectories<include-subdirs-coq>`.
 
 Here are the contents of the ``.v`` files:
@@ -570,7 +570,7 @@ The file ``comb.v`` looks like:
 We are referencing Coq modules from all three of our previously defined
 theories.
 
-Our :doc:`/reference/files/dune/index` file in ``CombinedWork`` looks like:
+Our :doc:`/reference/dune/index` file in ``CombinedWork`` looks like:
 
 .. code:: dune
 
@@ -655,7 +655,7 @@ Let us build a simple Coq plugin to demonstrate how Dune can handle this setup.
       ├── dune
       └── UsingMyPlugin.v
 
-Our :doc:`/reference/files/dune-project/index` will need to have a package for
+Our :doc:`/reference/dune-project/index` will need to have a package for
 the plugin to sit in, otherwise Coq will not be able to find it.
 
 .. code:: dune
@@ -669,8 +669,8 @@ the plugin to sit in, otherwise Coq will not be able to find it.
    (depends coq-core))
 
 Now we have two directories, ``src/`` and ``theories/`` each with their own
-:doc:`/reference/files/dune/index` file. Let us begin with the plugin
-:doc:`/reference/files/dune/index` file:
+:doc:`/reference/dune/index` file. Let us begin with the plugin
+:doc:`/reference/dune/index` file:
 
 .. code:: dune
 
@@ -684,7 +684,7 @@ Now we have two directories, ``src/`` and ``theories/`` each with their own
   (coq.pp
    (modules syntax))
 
-Here we define a library using the :doc:`/reference/files/dune/library` stanza.
+Here we define a library using the :doc:`/reference/dune/library` stanza.
 Importantly, we declared which external libraries we rely on and gave the
 library a ``public_name``, as starting with Coq 8.16, Coq will identify plugins
 using their corresponding findlib public name.
@@ -808,7 +808,7 @@ Dune.
 Coq Environment Fields
 ----------------------
 
-The :doc:`/reference/files/dune/env` stanza has a ``(coq <coq_fields>)`` field
+The :doc:`/reference/dune/env` stanza has a ``(coq <coq_fields>)`` field
 with the following values for ``<coq_fields>``:
 
 - ``(flags <flags>)``: The default flags passed to ``coqc``. The default value

doc/documentation.rst

@@ -30,7 +30,7 @@ files following the syntax described in the section ``Text formatting`` of
 the `OCaml manual <http://caml.inria.fr/pub/docs/manual-ocaml/ocamldoc.html>`_.
 
 Additional documentation pages may be attached to a package using the
-:doc:`/reference/files/dune/documentation` stanza.
+:doc:`/reference/dune/documentation` stanza.
 
 Building Documentation
 ======================
@@ -63,7 +63,7 @@ found in ``_build/default/_doc/_html/<library>``.
 Documentation Stanza: Examples
 ------------------------------
 
-The :doc:`/reference/files/dune/documentation` stanza will attach all the
+The :doc:`/reference/dune/documentation` stanza will attach all the
 ``.mld`` files in the current directory in a project with a single package.
 
 .. code-block:: dune
@@ -115,7 +115,7 @@ Passing Options to ``odoc``
      (<profile>
       (odoc <optional-fields>)))
 
-See :doc:`/reference/files/dune/env` for more details on the ``(env ...)``
+See :doc:`/reference/dune/env` for more details on the ``(env ...)``
 stanza. ``<optional-fields>`` are:
 
 - ``(warnings <mode>)`` specifies how warnings should be handled. ``<mode>``

doc/foreign-code.rst

@@ -53,7 +53,7 @@ Header Files
 
 C/C++ source files may include header files in the same directory as the C/C++
 source files or in the same directory group when using
-:doc:`/reference/files/dune/include_subdirs`.
+:doc:`/reference/dune/include_subdirs`.
 
 The header files must have the ``.h`` extension.
 
@@ -62,8 +62,8 @@ Installing Header Files
 
 It is sometimes desirable to install header files with the library. For that
 you have two choices: install them explicitly with an
-:doc:`/reference/files/dune/install` stanza or use the ``install_c_headers``
-field of the :doc:`/reference/files/dune/library` stanza. This field takes a
+:doc:`/reference/dune/install` stanza or use the ``install_c_headers``
+field of the :doc:`/reference/dune/library` stanza. This field takes a
 list of header files names without the ``.h`` extension. When a library
 installs header files, they are made visible to users of the library via the
 include search path.
@@ -292,10 +292,10 @@ descriptions by referencing them as the module specified in optional
 - ``(vendored (c_flags <flags>) (c_library_flags <flags>))`` provide the build
   and link flags for binding your vendored code. You must also provide
   instructions in your ``dune`` file on how to build the vendored foreign
-  library; see the :doc:`/reference/files/dune/foreign_library` stanza. Usually
+  library; see the :doc:`/reference/dune/foreign_library` stanza. Usually
   the ``<flags>`` should contain ``:standard`` in order to add the default
   flags used by the OCaml compiler for C files
-  :doc:`/reference/files/dune-project/use_standard_c_and_cxx_flags`.
+  :doc:`/reference/dune-project/use_standard_c_and_cxx_flags`.
 
 .. _foreign-sandboxing:
 
@@ -311,7 +311,7 @@ To do that, follow the following procedure:
 
 - Put all the foreign code in a sub-directory
 - Tell Dune not to interpret configuration files in this directory via an
-  :doc:`/reference/files/dune/data_only_dirs` stanza
+  :doc:`/reference/dune/data_only_dirs` stanza
 - Write a custom rule that:
 
   - depends on this directory recursively via :ref:`source_tree <source_tree>`

doc/howto/formatting.rst

@@ -14,7 +14,7 @@ First, let's open the ``dune-project`` file. Make sure that the version
 specified in ``(lang dune X.Y)`` is at least ``2.0``. Most formatting
 configuration happens in that file. If you want to format OCaml sources and
 ``dune`` files, you don't have anything to add. Otherwise, refer to the
-:doc:`/reference/files/dune-project/formatting` stanza.
+:doc:`/reference/dune-project/formatting` stanza.
 
 Next we need to install some code formatting tools. For OCaml code, this means
 installing OCamlFormat_ with ``opam install ocamlformat``. Formatting ``dune``

doc/howto/opam-file-generation.rst

@@ -44,7 +44,7 @@ For an Existing Package
 ^^^^^^^^^^^^^^^^^^^^^^^
 
 If you already have an opam file (or several of them), you can convert it by
-following the rules in :doc:`/reference/files/dune-project/package`.
+following the rules in :doc:`/reference/dune-project/package`.
 
 For example, if your opam file looks like: