From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 83E1E3858C54; Wed, 13 Jul 2022 22:35:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 83E1E3858C54 From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/106285] Reduce visual noise and confusing grouping when printing overload candidate errors Date: Wed, 13 Jul 2022 22:35:13 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: unknown X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: redi at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2022 22:35:13 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106285 --- Comment #2 from Jonathan Wakely --- Re the grouping of related notes, I notice that with -fdiagnostics-format= =3Djson there is no proper structure. All the notes are just children of the error,= at the same level. So the nesting is something like: error: no matching function for call to ... { location of failed call site, candidate: decl, reason for failure, location of decl, candidate: decl, reason for failure, location of decl, candidate: decl, reason for failure, location of decl, } Ideally we'd have this nesting: error: no matching function for call to ... { location of failed call site, candidate: decl { reason for failure, location of decl }, candidate: decl { reason for failure, location of decl }, candidate: decl { reason for failure, location of decl }, } i.e. the error would have the candidates as direct children, but then the locations and failure reason for each candidate would be children of the candidate. This would allow IDEs to group the info about each candidate and optionally collapse it. With the current (lack of) structure that's not possible. Every note is at the same level and there's no indication which ones are related = to each other.=