From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.6 Path: eternal-september.org!reader02.eternal-september.org!aioe.org!9CzwYWWlKVx8RMZd/VcwFg.user.46.165.242.75.POSTED!not-for-mail From: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: Problem with emacs ada-mode-7.1.4 Date: Mon, 19 Jul 2021 14:17:44 -0700 Organization: Aioe.org NNTP Server Message-ID: <868s22atqf.fsf@stephe-leake.org> References: <4e943274-59ad-497d-9ef1-5f5d096aea56n@googlegroups.com> <6b724d0f-3184-47f0-8266-c805406cf4b7n@googlegroups.com> <76673bec-53cc-4789-8f01-4a1d0d04e077n@googlegroups.com> <71c3d589-fd6f-4b5e-a9f3-394109b1fa05n@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: gioia.aioe.org; logging-data="27153"; posting-host="9CzwYWWlKVx8RMZd/VcwFg.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org"; User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (windows-nt) X-Notice: Filtered by postfilter v. 0.9.2 Cancel-Lock: sha1:BXtRo/0RfBDWloOwvMTmpdO8bjY= Xref: reader02.eternal-september.org comp.lang.ada:62415 List-Id: Simon Wright writes: > Paul Onions 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