[Bug rust/105914] New: gccrs setting warn_unused_variable breaks thousands of non-Rust tests

[Bug rust/105914] New: gccrs setting warn_unused_variable breaks thousands of non-Rust tests

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105914

            Bug ID: 105914
           Summary: gccrs setting warn_unused_variable breaks thousands of
                    non-Rust tests
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rust
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ro at gcc dot gnu.org
  Target Milestone: ---

I've just finished bootstrapping the devel/rust/master branch on all of
Linux/x86_64,
Linux/i686, Solaris/x86_64, and Solaris/x86 with --enable-languages=rust.

The rust testresults are fine everywhere, but one change badly breaks C and C++
tests like this:

FAIL: gcc.c-torture/compile/pr99787-1.c   -O0  (test for excess errors)
Excess errors:
/vol/gcc/src/git/rust/gcc/testsuite/gcc.c-torture/compile/pr99787-1.c:10:12:
warning: unused variable 'f' [-Wunused-variable]

There are several thousand failures like this, all over the place (gcc, g++,
libgomp, libitm, libstdc++).  I'm pretty certain this is due to this snippet
in gcc/rust/lang.opt:

Wunused-variable
Rust Var(warn_unused_variable) Init(1) Warning
; documented in common.opt

Obviously this causes the warning to default to on for every language, not just
for Rust.  I haven't tried looking how to avoid this.

[Bug rust/105914] gccrs setting warn_unused_variable breaks thousands of non-Rust tests

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105914

Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|13.0                        |rust/master
                 CC|                            |tschwinge at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |tschwinge at gcc dot gnu.org
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2022-06-10

--- Comment #1 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
Right, I've run into this, too.  (Bootstrap failure even, with Ada enabled.)

I have half-finished patches to address this, and also patches to improve GCC's
options machinery, to make it unlikely that similar breakage happens in the
future.  :-)

[Bug rust/105914] gccrs setting warn_unused_variable breaks thousands of non-Rust tests

[cohenarthur.dev at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105914

Arthur Cohen <cohenarthur.dev at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cohenarthur.dev at gmail dot com

--- Comment #2 from Arthur Cohen <cohenarthur.dev at gmail dot com> ---
Hi there :) This should be fixed now. We decided to enable the warning from
within the frontend instead of within the build files.

[Bug rust/105914] gccrs setting warn_unused_variable breaks thousands of non-Rust tests

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105914

Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://github.com/Rust-GCC
                   |                            |/gccrs/pull/1570
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #3 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
The issue at hand has been resolved via
<https://github.com/Rust-GCC/gccrs/pull/1570> "Apply #1560 master", and my
"patch series adding a 'LangInit(@var{language}, @var{value})' option property"
can then later be applied here, too, once I've got that completed...  ;-|