Can't initialize a new crate using the main branch of Alire with both amd64 and arm64 builds using GNAT 13

[dalybrown]

I'm trying to investigate why pins won't work for arm64 builds of alire but work for amd64 builds of Alire. I see this issue in v1.2.2. I decided I would use the main branch to investigate anyways. However, I can no longer even initialize a crate to reproduce the issue to investigate.

In looking into it, whenever I try to initialize a new crate (e.g., alr init --in-place --bin), an exception is raised. I see this both in the amd64 and arm64 builds of Alire (I built it and tested on both architectures). The following line is where the exception is raised:

https://github.com/alire-project/alire/blob/92896bd3a2147b20c4b8874675258f8baf9b9aa4/src/alire/alire-releases.adb#L878

The following is what alire prints to the console:

error: failed precondition from alire-roots-optional.ads:43
error: alr encountered an unexpected error, re-run with -d for details.

If you turn on verbose logging, you can see this printed to the console:

stderr: CONSTRAINT_ERROR
stderr: Unexpected property count: 0
stderr: raised CONSTRAINT_ERROR : Unexpected property count: 0

The property key it is looking for is NAME.

I should note I develop on a Mac M1 and run this inside a docker container. That shouldn't really affect much since every other tool in any language I develop in works, including other Ada/SPARK tools and previous versions of Alire (minus some features like pins...).

I'll use the version of Alire where I experience the pin issue to try to debug that but I thought I should raise this in case anyone else experiences it.

[dalybrown]

I switched to the v1.2.2 branch which I used to build and use and that too is experiencing this property count issue. Now I'm confused... the only change I've made since when I used to build it and currently build it is the compiler. This is the version of the compiler I am using:

GNAT 13.2.0
Copyright (C) 1996-2023, Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I was previously building it with 12.2.0-14 and it worked (minus pins). I guess this means there is an issue building Alire (regardless of architecture) using GNAT 13? The version of Alire in the debian package repo works fine (minus pins for arm64).

Update: I just built Alire v1.2.2 it with GNAT 12.2.0 and I can initialize and build a crate (minus pins in arm64). So somewhere along the way Alire can't be built with GNAT 13. Update 2: I also built the main branch of Alire with GNAT 12.2.0 and I can initialize and build a crate. I'll update the title to reflect that the issue manifests itself with gnat-13.

[cbvi]

I have this problem with alire 1.2 on OpenSUSE. Basically any alr command that operates on the toml fails, eg. alr show gives:

error: Cannot continue without a workspace:
error:    Failed to load alire.toml:
error:    Unexpected property count: 0

I was able to work around this by changing the function Loader in Alire.Properties.From_TOML to not use extended return syntax, simple patch: https://gist.github.com/cbvi/d67841603f9234503216144c2561ee12 With this patch applied it works.

Stepping through the code in gdb I'm not sure what is happening.

The problem starts from Load_Crate_Section at this line: (alire-toml_load.adb:209)

      Props := Props and
        Properties.From_TOML.Section_Loaders (Section) (From, Strict);

At this point Props is empty:

print Props
$3 = (reference => 0x0, busy => 0)

The Section_Loaders call goes through a few intermediary functions that dispatch to Alire.Properties.From_TOML.Loader which does an extended return on its own Props variable and enters a loop that puts values into it. This works; the loop runs several times populating Props. When it returns Props has a non-empty value:

32                        return; -- No more keys
(gdb) print Props
$6 = (reference => 0x15e0b50, busy => 0)

When it returns back to the calling line in Load_Create_Section, it enters the and operator, which is Alire.Conditional.For_Properties."and"

The LHS is the empty Props so that's fine

(gdb) print L
$10 = (reference => 0x0, busy => 0)

but the RHS should be the populated Props that was returned from From_TOML.Loader but instead it is also empty:

(gdb) print R
$11 = (reference => 0x0, busy => 0)

That's how it ends up with the empty property list that raises the exception.

Trying it on another system (FreeBSD) this doesn't happen, the RHS in the and is the same value that was returned:

(gdb) 32                        return; -- No more keys
(gdb) print Props
$6 = (reference => 0x801c2a6a0, busy => 0)

[...]

(gdb) print R
$9 = (reference => 0x801c2a6a0, busy => 0)

[mosteo]

I've seen strange bugs with expression functions in the past, but I'm surprised to see a regression in going to GNAT 13.

[dalybrown]

I've seen strange bugs with expression functions in the past, but I'm surprised to see a regression in going to GNAT 13.

There are some other regressions in GNAT 13 (e.g., https://github.com/AdaCore/RecordFlux/issues/1293).