Hello All,

Not sure if this is the right place to post this, but I have a problem compiling the Ada code after installing ada-mode 7.1.4 as a package in Gnu Emacs 27.2.

Specifically, when I cd into ~/.emacs.d/elpa/ada-mode-7.1.4/ and issue the command ./build.sh I get the following:-

....
Compile
[Ada] ada_mode_wisi_lalr_parse.ads
[Ada] ada_mode_wisi_lr1_parse.ads
[Ada] run_ada_lalr_parse.ads
[Ada] run_ada_lr1_parse.ads
[Ada] gpr_mode_wisi_parse.ads
[Ada] run_gpr_parse.ads
[Ada] gpr_query.adb
[C] wisitoken_grammar_re2c.c
sal-gen_unbounded_definite_vectors.adb:452:10: access discriminant in return object would be a dangling reference
sal-gen_unbounded_definite_vectors.adb:454:10: access discriminant in return object would be a dangling reference
sal-gen_unbounded_definite_vectors.adb:456:10: access discriminant in return object would be a dangling reference
sal-gen_unbounded_definite_vectors.adb:474:10: access discriminant in return object would be a dangling reference
sal-gen_unbounded_definite_vectors.adb:476:10: access discriminant in return object would be a dangling reference
sal-gen_unbounded_definite_vectors.adb:478:10: access discriminant in return object would be a dangling reference
sal-gen_unbounded_definite_vectors.adb:532:10: access discriminant in return object would be a dangling reference
sal-gen_unbounded_definite_vectors.adb:534:10: access discriminant in return object would be a dangling reference
sal-gen_unbounded_definite_vectors.adb:543:10: access discriminant in return object would be a dangling reference
sal-gen_unbounded_definite_vectors.adb:545:10: access discriminant in return object would be a dangling reference
sal-gen_unbounded_definite_vectors.adb:552:10: access discriminant in return object would be a dangling reference
sal-gen_unbounded_definite_vectors.adb:554:10: access discriminant in return object would be a dangling reference
sal-gen_unbounded_definite_vectors.adb:561:10: access discriminant in return object would be a dangling reference
sal-gen_unbounded_definite_vectors.adb:563:10: access discriminant in return object would be a dangling reference
....

I'm using GCC 11.1.0 from the download at https://github.com/simonjwright/building-gcc-macos-native, on macOS Big Sur.

Any help appreciated. Thanks,
Paul

Paul Onions <ponions37@gmail.com> writes:

> Not sure if this is the right place to post this, but I have a problem
> compiling the Ada code after installing ada-mode 7.1.4 as a package in
> Gnu Emacs 27.2.
[...]
> sal-gen_unbounded_definite_vectors.adb:452:10: access discriminant in
> return object would be a dangling reference
[...]
> I'm using GCC 11.1.0 from the download at
> https://github.com/simonjwright/building-gcc-macos-native, on macOS
> Big Sur.

There has been a problem in this area for a while now. I compiled the
ada-mode I'm using (successfully) with GNAT CE 2019.

Hello Simon,

On Saturday, 17 July 2021 at 22:18:16 UTC+1, Simon Wright wrote:
> There has been a problem in this area for a while now. I compiled the
> ada-mode I'm using (successfully) with GNAT CE 2019.

Thanks for responding. I just tried that but now I get:-

ada_mode_wisi_parse.gpr:22:06: unknown project file: "gnatcoll_sqlite"
ada_mode_wisi_parse.gpr:23:06: unknown project file: "gnatcoll_xref"

So I assume I need to install these gnatcoll components. I downloaded gnatcoll-db-21.0.0 from AdaCore's GitHub presence, but trying to build gnatcoll_sql I get:-

....
Compile
[Ada] gnatcoll-sql-exec-tasking.adb
[Ada] gnatcoll-sql-inspect.adb
[Ada] gnatcoll-sql_fields.adb
[Ada] gnatcoll-sql_impl.adb
gnatcoll-sql_impl.adb:1679:44: "UTC_Time_Offset" is not visible (more references follow)
gnatcoll-sql_impl.adb:1679:44: non-visible declaration at a-catizo.ads:28
gnatcoll-sql_impl.adb:1679:44: non-visible declaration at a-calend.ads:403
....

I also tried with GNAT CE 2020 but get the same results. I'm guessing that UTC_Time_Offset is maybe a recent addition to one of the Ada/GNAT packages USEd by gnatcoll-sql_impl.adb?

Slightly confused,
Paul

On 2021-07-18 10:43, Paul Onions wrote:

> I'm guessing that UTC_Time_Offset is maybe a recent addition to one of the Ada/GNAT packages USEd by gnatcoll-sql_impl.adb?

That depends on personal perception. To me year 2005 is like yesterday
(:-()

https://www.adaic.org/resources/add_content/standards/05rm/html/RM-9-6-1.html#I3765

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Hi Dmitry,

On Sunday, 18 July 2021 at 10:00:43 UTC+1, Dmitry A. Kazakov wrote:
> https://www.adaic.org/resources/add_content/standards/05rm/html/RM-9-6-1.html#I3765

That's interesting, so it's in Ada.Calendar.Time_Zones from Ada2005, but that is not one of the packages USEd by gnatcoll-sql_impl.adb. So I'm guessing it was added to one of the GNAT packages later.

Anyway, I cloned the gnatcoll-db git repository and found a "20-sustained" branch in there. Switching to it then allowed me to build gnatcoll_sqlite with GNAT CE 2020. Yay.

However, trying to build gnatcoll_xref failed because it's looking for something called gnatcoll_iconv, which I don't see anywhere in the repository. Need to go looking for that now (or rather later, when I've more time)...

Paul

So I've finally managed to get ada-mode installed and working with GNAT CE 2020. For the record here's what I did (in case it's useful to others):-

1. Cloned git repositories gnatcoll-db and gnatcoll-bindings from github.com/AdaCore/, checked out branch "20-sustained" in both repositories then built and installed gnatcoll_iconv (in gnatcoll-bindings), and gnatcoll_xref, gnatcoll_sql, gnatcoll_sqlite (in gnatcoll-db).

2. In ~/.emacs.d/elpa/ada-mode-7.1.4/ ran ./build.sh, which failed with an error message about file sal-gen_unbounded_definite_red_black_trees.adb. So went to that file in ~/.emacs.d/elpa/wisi-3.1.3/, read the comments tagged with "WORKAROUND" and deleted the appropriate ".all" components. Reran ./build.sh which completed successfully and then ran ./install.sh, also successful.

3. Opened an Ada file and watched Emacs complain about a void-function called wisi--lexer-error. Enabled the Emacs debugger and looked in the traceback. Message seems to be coming from compiled byte-code, so I deleted all .elc files in the wisi-3.1.3 directory and tried again. Now I get a message saying ada_mode_wisi_lr1_parse cannot be found on exec-path, so I go look for it and end up adding the GNAT CE 2020 bin path to exec-path in my Emacs setup and now finally it's working! Phew.

I have one question: was my original problem a bug in the ada-mode code or is it a bug in the latest GNAT compiler? (GCC 11.1.0)

Thanks,
Paul

Paul Onions <ponions37@gmail.com> writes:

> I have one question: was my original problem a bug in the ada-mode
> code or is it a bug in the latest GNAT compiler? (GCC 11.1.0)

Just had a poke around.

GNAT CE 2019, using the matching gnatcoll-db and gnatcoll-bindings from
the CE download site, worked OK.

CE 2020, with its matching bindings, required the WORKAROUND changes to
build.

CE 2021, with its matching bindings, failed in *exactly the same way* as
FSF GCC 11.1.0!! There was an interesting thread about this at [1]; I'm
not sure from that whether the ada-mode code is OK or not, but it seems
that even if it is we'll have to wait for a later compiler release.

The lesson I'd draw is that building your own container collection is
risky. At least if you start from Ada.Containers you have a reasonably
firm basis.

With regard to "matching bindings" above, these can be found at the CE
download site[2]. Find the compiler release you want the bindings for
(we Mac users are better off going for the x86 GNU Linux (64 bits)
version) and click on the Sources link. For CE 2021, you'll find -core
and -bindings but not -db; I see that I used the v21.0.0 tag from
AdaCore's github repo when I built the binary CE 2021 distribution
you'll find at [3].

[1]
https://groups.google.com/g/comp.lang.ada/c/7dw7Oqi8lIk/m/t6UJkTIHDQAJ
[2] https://www.adacore.com/download/more
[3] https://github.com/simonjwright/distributing-gcc/releases/tag/gnat-ce-2021

Paul Onions <ponions37@gmail.com> writes:

> Not sure if this is the right place to post this,

This is ok; the ada-mode mailing list at
https://savannah.nongnu.org/projects/ada-mode/ is better.

> but I have a problem compiling the Ada code after installing ada-mode
> 7.1.4 as a package in Gnu Emacs 27.2.
>
> Specifically, when I cd into ~/.emacs.d/elpa/ada-mode-7.1.4/ and issue
> the command ./build.sh I get the following:-

> sal-gen_unbounded_definite_vectors.adb:452:10: access discriminant in
> return object would be a dangling reference

This is due to a change in your version of GNAT vs the one I tested with
(better dangling reference detection); switch to Community 2020.

> I'm using GCC 11.1.0 from the download at
> https://github.com/simonjwright/building-gcc-macos-native, on macOS
> Big Sur.

Ok.

I have a fix for this in the development version of ada-mode. I didn't
realize this version of GNAT was in FSF gcc yet.

--
-- Stephe

On Sunday, 18 July 2021 at 17:24:11 UTC+1, Simon Wright wrote:
> There was an interesting thread about this at [1]; I'm
> not sure from that whether the ada-mode code is OK or not, but it seems
> that even if it is we'll have to wait for a later compiler release.

Thanks for looking further into it. Not sure I'm qualified enough in the Ada world to properly follow the discussion in the thread you link to -- I'll try to spend some on it later :-)

Thanks,
Paul

Hi Stephen,

On Sunday, 18 July 2021 at 18:03:13 UTC+1, Stephen Leake wrote:
> Paul Onions writes:
> > Not sure if this is the right place to post this,
> This is ok; the ada-mode mailing list at
> https://savannah.nongnu.org/projects/ada-mode/ is better.

Okay, thanks, I'll try to remember in future :-)

> I have a fix for this in the development version of ada-mode. I didn't
> realize this version of GNAT was in FSF gcc yet.

Okay, sounds good, look forward to trying it out.

Thanks,
Paul

Paul Onions <ponions37@gmail.com> writes:

> On Sunday, 18 July 2021 at 17:24:11 UTC+1, Simon Wright wrote:
>> There was an interesting thread about this at [1]; I'm not sure from
>> that whether the ada-mode code is OK or not, but it seems that even
>> if it is we'll have to wait for a later compiler release.
>
> Thanks for looking further into it. Not sure I'm qualified enough in
> the Ada world to properly follow the discussion in the thread you link
> to -- I'll try to spend some on it later :-)

Not many of us are. That chapter in the ARM (3.10.2) is known as the
Heart of Darkness for a reason. See AARM 3.10.2(3.a, b)[1].

While poking at the ada-mode code, I found that avoiding anonymous
accesses (especially when used as discriminants) went a long way to
quieting the compiler; and the use of 'Unchecked_Access also helped.

[1]: http://www.ada-auth.org/standards/aarm12_w_tc1/html/AA-3-10-2.html#p3.a

Paul Onions <ponions37@gmail.com> writes:

> Anyway, I cloned the gnatcoll-db git repository and found a
> "20-sustained" branch in there. Switching to it then allowed me to
> build gnatcoll_sqlite with GNAT CE 2020. Yay.

I'll add that to the ada-mode.info install instructions.

> However, trying to build gnatcoll_xref failed because it's looking for
> something called gnatcoll_iconv, which I don't see anywhere in the
> repository. Need to go looking for that now (or rather later, when
> I've more time)...

See the install instructions in ada-mode.info; it's in another github
repo; gnatcoll-bindings.

--
-- Stephe

Simon Wright <simon@pushface.org> writes:

> Paul Onions <ponions37@gmail.com> writes:
>
>> I have one question: was my original problem a bug in the ada-mode
>> code or is it a bug in the latest GNAT compiler? (GCC 11.1.0)
>
> Just had a poke around.
>
> GNAT CE 2019, using the matching gnatcoll-db and gnatcoll-bindings from
> the CE download site, worked OK.
>
> CE 2020, with its matching bindings, required the WORKAROUND changes to
> build.
>
> CE 2021, with its matching bindings, failed in *exactly the same way* as
> FSF GCC 11.1.0!! There was an interesting thread about this at [1]; I'm
> not sure from that whether the ada-mode code is OK or not, but it seems
> that even if it is we'll have to wait for a later compiler release.

I think the latest gnat compiler is more correct, so the bug is in the
ada-mode code. There is a fix in the devel version of ada-mode (it still
has workarounds for a remaining compiler bug I found while creating that
fix).

I think you can access that devel version of ada-mode via the "bleeding
edge" elpa repository, which serves the HEAD versions instead of the
release versions. But I can't find any instructions on how to do that in
the ELPA docs.

> The lesson I'd draw is that building your own container collection is
> risky.

More generally, trusting the compiler to check use of access types, by
never using 'Unchecked_Access.

> At least if you start from Ada.Containers you have a reasonably firm
> basis.

I question "firm"; they use 'Unchecked_Access internally, and they are
not written in Spark. The best you can say is "maintained by AdaCore",
which nominally means any bugs exposed by compiler updates are fixed
before the compiler updates are released.

I posit that I have more experience writing Ada code than many of the
people now at AdaCore :).

Some of the containers in ada-mode that are required to be fast (because
they are used a lot in error recovery) are written in Spark; they use
bounded data storage, not allocation. Some are not, because they require
allocation. Spark has lately added some support for allocation; I'll
have to check if that means I can now migrate those containers to Spark.

> With regard to "matching bindings" above, these can be found at the CE
> download site[2].

As you point out, that has gnatcoll-bindings, but not gnatcoll-db;
gnatcoll-db is only available via github. ada-mode.info currently says
to get gnatcoll-bindings from github; I'll change that.

A recent exchange with AdaCore indicated that packages on github are
_not_ supported (even with a support contract). Which I did not know
before, and is yet another reason to switch to libadalang (which is
supported).

--
-- Stephe