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-65-14.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!vNObJwB5W4WN632vBkQn9g.user.46.165.242.75.POSTED!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: Aggregate with (parens) considered obsolescent Date: Mon, 11 Apr 2022 17:15:08 +0100 Organization: Aioe.org NNTP Server Message-ID: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: gioia.aioe.org; logging-data="39364"; posting-host="vNObJwB5W4WN632vBkQn9g.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org"; User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (darwin) X-Notice: Filtered by postfilter v. 0.9.2 Cancel-Lock: sha1:gDhmEXV1rJ5IFXseMQAgpCDngjQ= Xref: reader02.eternal-september.org comp.lang.ada:63732 List-Id: GCC 12. with the -gnat2022 switch, supports (a large part of) ARM 2022. One of the changes is AI12-0212[1], the use of square brackets [] in array aggregates. I was surprised to find that the compiler reports the use of parentheses () for array aggregates as obsolescent! To quote PR104751[2], ============= Compiling procedure New_Syntax is T : array (1 .. 5) of Integer; begin T := (1, 2, 3, 4, 5); end New_Syntax; with -gnat2022 -gnatwj gives new_syntax.adb:4:09: warning: array aggregate using () is an obsolescent syntax, use [] instead [-gnatwj] but use of parens is not in Annex J; use of brackets is an option, AARM 202x Draft 32, 4.3.3(49.m). Having -gnatwj as part of -gnatwa makes this very intrusive. ============= The fact that it happens with -gnatwa, which is a switch that I suspect quite a lot of us use, will be particularly annoying for those who use -gnatwe (treat warnings as errors) and who want to support multiple compiler releases (for example, the Ada Drivers Library). The response dismissing the PR suggested using pragma Warnings (Off, "*array aggregate*"); and one glimmer of hope is that this can be used as a configuration pragma. I could remove the problem from macOS releases that I support (sem_aggr.adb:1803..1815), but of course that would lead users into problems when using another GCC 12+ release. [1] http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai12-0212-1.txt?rev=1.29&raw=N [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104751