Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(coq): delay loading rules for resolving coqc #9369

Closed

Conversation

rgrinberg
Copy link
Member

Signed-off-by: Rudi Grinberg me@rgrinberg.com

Signed-off-by: Rudi Grinberg <me@rgrinberg.com>

<!-- ps-id: 76f077ec-d88b-4878-a538-c72deab5b9cd -->
@rgrinberg rgrinberg force-pushed the ps/rr/fix_coq___delay_loading_rules_for_resolving_coqc branch from 4e261e6 to 5bd15b3 Compare December 3, 2023 19:11
@rgrinberg rgrinberg added the coq label Dec 4, 2023
@Alizter
Copy link
Collaborator

Alizter commented Dec 4, 2023

This resolves the issue where the test in #7908 was hanging. We now have the more useful:

  Internal error, please report upstream including the contents of _build/log.
  Description:
    ("internal dependency cycle",
    { frames =
        [ ("build-file", In_build_dir "default/coqc")
        ; ("coq-config", In_build_dir "default/coqc")
        ; ("<unnamed>", ())
        ; ("load-dir", In_build_dir "default")
        ]
    })

Which @ejgallego and I can look into further.

@rgrinberg
Copy link
Member Author

That one is expected. Just move the coq binary into a different directory and it will work.

@@ -2,6 +2,11 @@ open Import

type t

type origin =
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this type be documented?

@@ -19,4 +24,12 @@ val binary : t -> ?hint:string -> loc:Loc.t option -> string -> Action.Prog.t Me

val binary_available : t -> string -> bool Memo.t
val add_binaries : t -> dir:Path.Build.t -> File_binding.Expanded.t list -> t
val create : Context.t -> local_bins:Path.Build.Set.t Memo.Lazy.t -> t

val binary_with_origin
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add some documentation to this new API?

Copy link
Member Author

@rgrinberg rgrinberg Dec 4, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I will add docs and explanations. I'm just still contemplating getting rid of the old behavior of loading binaries in the install directory everywhere. I don't remember why it's like that in the first place, so I'm digging through git history for a clue.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot for the PR and for the explanation; I'm testing the patch

This comment was marked as outdated.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I spoke too early, I had forgotten to bump the Coq lang to 0.7, indeed the problem with Coq persists, I get:

Error: Dependency cycle between:
   Computing installable artifacts for package coqide-server
-> required by Computing installable artifacts for package coq-core
-> required by _build/default/coq-core.install
-> required by alias default in dune:22

and dune hangs.

~dir
sw)
in
Ok (Path.build (File_binding.Expanded.dst_path expanded ~dir))
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this dst_path? Shouldn't I expand it into the source path?

cc @ejgallego

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is just because of the initial compose with Coq patch using Super_context.resolve_program which indeed seems to resolve to the expanded path, it shouldn't matter for Coq, as we run it in such a way that is fully re-locatable (provided the deps of Coq are too, of course)

@rgrinberg
Copy link
Member Author

Replaced by #9496

@rgrinberg rgrinberg closed this Dec 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants