Closed vbramselaar closed 2 months ago
Thanks for reporting the issue here, we are looking into it.
Hello,
This seems to be a consequence of how alr and gnatprove are designed. Alire likes to make the entire source tree available, including dependencies, but this means SPARK will analyze it. There is currently no way to avoid this.
Note that the error you saw is a bug and has been fixed in the compiler. It will be available in next year's FSF compiler release.
Alire likes to make the entire source tree available, including dependencies, but this means SPARK will analyze it. There is currently no way to avoid this.
I kinda have one workaround. Where I created another .gpr file which only mentioned the sources of SPARK code I want to verify (it would not really compile or anything). So the main file was from alire and another just for mentioning the spark code and run gnatprove on it.
Yes, creating a separate project for analysis is a solution to avoid this issue. Another solution is to use scenario variables in your project to avoid code duplication.
When creating a basic project with gnatcoll as dependency
gnatprove
fails. The error comes fromgpr-err-scanner.adb
it looks like. I reported the issue here because that was said here: https://github.com/AdaCore/gprbuild/issues/150.Issue
Steps to reproduce
alr init --bin test
cd test
alr with gnatcoll
alr with gnatprove
alr build
alr gnatprove