[Bug box] Rebuilding after adding dependency in project with pinned crates causes bug box

[damaki]

Checklist

• I've included the output of alr version.
• I've included complete steps to reproduce my issue.

Describe the bug
I have a project consisting of multiple crates, and since the project is unreleased I am using pins between my crates. When I added a dependency on an external library and tried to rebuild, I encountered the following Alire bug box when running alr build:

ERROR: ******************* BEGIN Alire bug detected *******************
ERROR: Location  : 0x7ff62343fdc5 Semantic_Versioning.Basic.Restrictions.First_Index at alire-solutions.adb:1543
ERROR: Extra info: No release visited in round 3
ERROR: Report at : https://github.com/alire-project/alire/issues/new?title=[Bug%20box]
ERROR: Re-run with `-vv -d` for a full log and stack trace.
ERROR: ******************** END Alire bug detected ********************

I have created a reproducer here: alr_bug.zip. See the steps below on how to reproduce.

There are four crates: A, B, C, and D. The first three are library crates, and the last (D) is an executable. The dependencies and pins between the four crates and the external crate (xoshiro in this case) are as follows:

graph LR
D[crate_d] --depends-on--> C[crate_c]
C --depends-on--> B[crate_b]
C --depends-on--> X[xoshiro]
B --depends-on--> A[crate_a]

D --pins-->C
C --pins--> B
B --pins--> A

Loading

To Reproduce
Steps to reproduce the behavior:

1. Download and extract the reproducer: alr_bug.zip
2. Run cd crate_d then alr build
3. Run cd ../crate_c then alr -n with xoshiro
4. Run cd ../crate_d then alr build
5. See the error

The error only seems to occur when crate_d has been previously built before doing the alr with command. If I delete the crate_d/alire/ directory after the bug box occurs and then do alr build again, then the bug box goes away and it works as expected.

Expected Behavior
The dependencies are resolved and the projects are built.

alr version

APPLICATION
alr version:               2.0.2+9b80158
libalire version:          2.0.2+9b80158
compilation date:          2024-10-09 17:02:15
compiled with version:     14.2.0

CONFIGURATION
settings folder:           C:\Users\Dan\AppData\Local\alire\settings
cache folder:              C:\Users\Dan\AppData\Local\alire\cache
vault folder:              C:\Users\Dan\AppData\Local\alire\cache\releases
build folder:              C:\Users\Dan\AppData\Local\alire\cache\builds
temp folder:               C:\Users\Dan\AppData\Local\Temp
force flag:                FALSE
non-interactive flag:      FALSE
community index branch:    stable-1.3.0
compatible index versions: ^1.1 & <=1.3.0
indexes folder:            C:\Users\Dan\AppData\Local\alire\settings\indexes
indexes metadata:          OK
index #1:                  (community) git+https://github.com/alire-project/alire-index#stable-1.3.0
toolchain folder:          C:\Users\Dan\AppData\Local\alire\cache\toolchains
toolchain assistant:       disabled
tool #1 gnat:              gnat_native=14.2.1
tool #2 gprbuild:          gprbuild=22.0.1
system package manager:    not found: unknown package manager
distro detection disabled: FALSE

WORKSPACE
root status:               VALID
root release:              crate_d=0.1.0-dev
root load error:           none
root folder:               D:\projects\ada\alr_bug\crate_d
current folder:            D:\projects\ada\alr_bug\crate_d

SYSTEM
distribution:              DISTRIBUTION_UNKNOWN
host-arch:                 X86_64
os:                        WINDOWS
target:                    NATIVE
toolchain:                 USER
word-size:                 BITS_64

[mosteo]

Thanks for the detailed report and reproducer.

This is likely a duplicate of #1662, could you please check if running alr update in the root crate (crate_d) before building fixes the issue?

[mgrojo]

I reproduced this with a nested crate and a pinned dependency to ... After alr update on the nested crated, the problem disappeared.

I also wanted to point out, that the bug-box tells you to repeat the command with -vv -d but doesn't tell you the position or that they are global switches. It took me some time to get that it had to be alr -vv -d build and not alr build -vv -d.

[damaki]

Thanks for the detailed report and reproducer.

This is likely a duplicate of #1662, could you please check if running alr update in the root crate (crate_d) before building fixes the issue?

I just tested it and yes, running alr update before building fixes the issue.

[mosteo]

the bug-box tells you to repeat the command with -vv -d but doesn't tell you the position or that they are global switches.

Fair point.