(Some) Imports from Coq standard library make the background compilation fail

[proofgeneral]

(Some) Imports from Coq standard library make the background compilation fail

[Matafou]

AFAIK Coq.Permutation does not exists as a library.

The Permutation file in coq theories has long name Coq.Sorting.Permutation.Permutation.
You can use any suffix of this (in particular Permutation alone), but not Coq.Permutation.

I close the bug, but feel free to reopen if you think I missed something.

[RalfJung]

Well, the point is, if I disable PG's background compilation, the file works fine. (With Coq 8.5.)

However, I can see that my minimal example does not. Will have to investigate.

(Also, GitHub does not allow me to re-open the bug.)

[RalfJung]

D'oh, okay, so this one is on me. I thought I could reproduce the bug with just the plain "Require Export" form, but actually I can only trigger it with the new "From ... Require Export" form:

From Coq Require Export Permutation.

It seems that while by PR #50 started support for that, it's not yet complete.

[Matafou]

I see. the PR #50 has not yet been merged, but will soon be.

[RalfJung]

I suppose the problem is that with From A Require B, Coq actually imports A....B, filling in an arbitrary path. I am not sure how PG should best handle this.

[JasonGross]

For what it's worth, I handle this by, essentially, asking Coq to compile From A Require B, and inspecting the glob file (which is created even if the file compilation fails, thankfully) to see what absolute name it inferred. Another option is to issue Locate Module B and filter for the ones starting with A.

[cpitclaudel]

Reopening this; the real issue is that From A Import B doesn't mean Import A.B, but "Import something of the name A.??.B". (Is that correct). This seems to be a blocker for merging #50, so it's good to keep it open as something to remember while working on that.

[cpitclaudel]

Jason, does that work even if B isn't compiled yet? The context in which this popped up was PG's on-the-fly compilation.

[JasonGross]

Oh. How about running coqdep with the relevant arguments on a new file with only the From ... Require ... command?

[JasonGross]

Or, better, why not just run coqdep? Is it because you don't have COQBIN or something?

[cpitclaudel]

I'm not sure; I didn't write the compilation code :) @hendriktews did, IIRC. Hendrik, opinions?

[Matafou]

I think I remember that running coqdep (or make) was an option in Hendrik's code. @hendriktews maybe this is time to remove the part of the code that mimicks coqdep and rely only on coqdep?

[Matafou]

I read the code and it seems that by default coqdep is iused to compute dependencies. This PR should therefore be mostly correct. I will try to test soon.

[RalfJung]

I have not changed my configuration, and I am seeing these failures for every file with From Coq Require Import .... So this does not seem to help.

I believe it is using coqdep only to extract the transitive dependencies of whatever is being imported; it still uses the hand-rolled regexp's to find the initial thing to import.

[Matafou]

I found two problems

1- The code uses coqdep, but it needs to give an argument to coqdep: the name of a file. This part of the code is wrong in presence of From. We need to search recursively inside directories to find where a file is located, then calling coqdep on it should be ok.

2- It seems that coqdep is sometimes called with -Q . "" with coq-8.5, which is wrong and supposedly fixed already.

P.

[RalfJung]

We need to search recursively inside directories to find where a file is located, then calling coqdep on it should be ok.

Well, but then we have to figure out that directory first. It may well be somewhere inside the Coq stdlib.

Can't we generate a new file containing only the From ... Require ... line, and run coqdep on that?

[Matafou]

OK I think I spotted the source of the problem.

Currently what your patch does is from

From foo Require bar.

compute a module name foo.bar

Which is wrong. the actual module name is probably something foo.foo1.foo2.bar.

The code of Hendrik works by generating a smal file with only Require foo.bar and calls coqdep to see where coq find the file.

The solution is to not concat the prefix foo to bar, but instead build a temporary file with the complete From ... Require ... command.

I will try to fix this.
P.

[Matafou]

Should be fixed now. thanks for reporting (and for the PR).