From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 9ECC23858437 for ; Mon, 13 Dec 2021 23:00:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9ECC23858437 Received: from mail-yb1-f197.google.com (mail-yb1-f197.google.com [209.85.219.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-445-EgoMb75EM9qHwh6yM-O8JQ-1; Mon, 13 Dec 2021 18:00:40 -0500 X-MC-Unique: EgoMb75EM9qHwh6yM-O8JQ-1 Received: by mail-yb1-f197.google.com with SMTP id g36-20020a25ae64000000b005c1f46f7ee6so33312960ybe.8 for ; Mon, 13 Dec 2021 15:00:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/aXRFuvaFDyVGWeUDDt/C792Wk1eRzIx9tl3r+Wrpeg=; b=3YGl6gJc/KCRDb/CWzppHpkxjxNxD/YrHjHWcAvJyZZ+81WZRgMylH28Qm6sX3E5Hk Wej6FgIXTxLTYkS81SGqkhdYpcFMPmBqRtAmMnf971cNLB/CttnuhxjPm6kIsDrtsSvw /+XRGDPffnGk+C0Uo71nZ3EbdxgHod7KxE5+sm6Nbfz9AvaMvGKOARTgS4JfXUAEO7q6 fR0pvvzJx8JJSrrCMcIli8h/1twVDqDhx4T7LMHNfrHIHRlfkNYAuqwyErH5FwS9Lo64 X/8DD+uZa1mgzRdYzahfVnn2bsCDbPWrgiCrGgY6BKpee6WuuSF8FJw7Zky6Ng89z4HG DClA== X-Gm-Message-State: AOAM530XZiKtvkIyEREEwY2x1up7eOCAE4nrdG92TXr2BCzKBxAM0dkI 5zraaMvndWdB6ums2DM3Peejn8TimqL+TiXz3/t/v0c19/HsvhLPcoyINltZA9SVmlxnubReQkY sYmsMlNy6/c50TntHJV6AeiKErslXXlcoxQ== X-Received: by 2002:a05:6902:1501:: with SMTP id q1mr2042268ybu.580.1639436440328; Mon, 13 Dec 2021 15:00:40 -0800 (PST) X-Google-Smtp-Source: ABdhPJxRkge5kmBXhC0Y3BXbqh0nCzDrHdDGhxUqDvFnF2zVUW4l5a2sJ5fBwFRDx92pNKlQ9XjaFgtP3fG9yKYy4Mc= X-Received: by 2002:a05:6902:1501:: with SMTP id q1mr2042235ybu.580.1639436440109; Mon, 13 Dec 2021 15:00:40 -0800 (PST) MIME-Version: 1.0 References: <20211212053942.240160-1-jason@redhat.com> <0298dda7-3323-c44c-f164-c09a4491e069@gmail.com> In-Reply-To: <0298dda7-3323-c44c-f164-c09a4491e069@gmail.com> From: Jonathan Wakely Date: Mon, 13 Dec 2021 23:00:29 +0000 Message-ID: Subject: Re: [PATCH RFC] c++: add color to function decl printing To: Martin Sebor Cc: Jason Merrill , gcc Patches X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Spam-Status: No, score=-7.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2021 23:00:45 -0000 On Mon, 13 Dec 2021 at 19:22, Martin Sebor wrote: > On 12/11/21 10:39 PM, Jason Merrill via Gcc-patches wrote: > > In reading C++ diagnostics, it's often hard to find the name of the > function > > in the middle of the template header, return type, parameters, and > template > > arguments. So let's colorize it, and maybe the template argument > bindings > > while we're at it. > > > > I've somewhat arbitrarily chosen bold green for the function name, and > > non-bold magenta for the template arguments. I'm not at all attached to > > these choices. > > > > A side-effect is that when this happens in a quote (i.e. %qD), the > > rest of the quote after the function name is no longer bold. I think > that's > > acceptable; returning to the bold would require maintaining a colorize > stack > > instead of the on/off controls we have now. > > > > Any thoughts? > > I appreciate the problem but I can't say I find this solution > much of an improvement. We end up with the same name in up to > four colors: cyan, magenta, green, and black, plus bold versions > of each, depending on where in the text the name appears. It's > not apparent to me what the different colors mean or how they > help. > They break up the wall of text. You don't have to know what they mean to be able to see where one chunk of text ends and another begins (in a different colour). The colours don't *mean* anything, they're just a way to distinguish different logical parts of the output. > IMO, the underlying root cause for why relevant details are so > hard to find in G++ messages is that there's so much redundancy > and irrelevant context in the output. For instance, for this > test case: > > #include > > std::map m ("123", "456"); > > For this example, I think putting the [with T = ...; U = ...] template arguments in a different colours helps a lot. It delineates the end of the signature and the start of the template args, which helps navigate the wall of text. I don't think anybody can argue that it's easier when the [with T = ...] part is just a continuation of the text before it. Making it a different colour doesn't necessarily make the errors easier to understand if you're not familiar with the code or GCC's diagnostic format, but I definitely think it makes it easier to navigate. And that should make it easier to figure out what the error is saying.