From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 35564 invoked by alias); 12 Nov 2018 21:32:05 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 35549 invoked by uid 89); 12 Nov 2018 21:32:04 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=books, H*f:sk:CAMfHzO, H*i:sk:1541970, H*f:sk:4d63c32 X-HELO: mail-qk1-f194.google.com Received: from mail-qk1-f194.google.com (HELO mail-qk1-f194.google.com) (209.85.222.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 12 Nov 2018 21:32:02 +0000 Received: by mail-qk1-f194.google.com with SMTP id w204so15999642qka.2 for ; Mon, 12 Nov 2018 13:32:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=ObK1V4qWcUJlxiG1fAchkVGWZ8M1KkIP+o+LfLgsRMQ=; b=EeCe2p9rUTqmW6Th1duzbHb1eKOEzVJN3+4PI4OQ0peItWRAW7ZAkPJdPOxG9fnCYG EwWHJHxTatvLo6b/GZT9uZvb5AtbyZ4DmDcaKHjhSdsbxDu1HDGZGKQCsPgZq1T2whMi nkOPEyJVh+TVqUI6QjXGfBFbfyvbQMtZmShySSAoNKiqmnB3w0fHH8jczsGyg8LQ0fft k1DFgjJt6zDH6l1Upy+Jj0jEI4K5MUpegxXLfLx/NgKxizFJawsUlWe57xaWBx1A1Rfw Laxl7ItxCfiirHO/z4q0RuHBe5xRyDqi1hsYl5UlQP5j7FMb9FFXSKP2QroJQxxJdMRT U9KA== Return-Path: Received: from localhost.localdomain (184-96-239-209.hlrn.qwest.net. [184.96.239.209]) by smtp.gmail.com with ESMTPSA id q38sm3083725qtj.65.2018.11.12.13.31.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Nov 2018 13:31:59 -0800 (PST) Subject: Re: [PATCH] C/C++: add fix-it hints for missing '&' and '*' (PR c++/87850) To: David Malcolm , Eric Gallager References: <1541805824-3745-1-git-send-email-dmalcolm@redhat.com> <4d63c323-14d1-59b7-aead-55a24ee68a85@gmail.com> <1541970156.4619.19.camel@redhat.com> Cc: gcc-patches@gcc.gnu.org From: Martin Sebor Message-ID: <01497f9d-ff8a-ca8c-2bc4-3aabd6b9361a@gmail.com> Date: Mon, 12 Nov 2018 21:32:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1541970156.4619.19.camel@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-11/txt/msg00998.txt.bz2 On 11/11/2018 02:02 PM, David Malcolm wrote: > On Sun, 2018-11-11 at 11:01 -0700, Martin Sebor wrote: >> On 11/10/2018 12:01 AM, Eric Gallager wrote: >>> On 11/9/18, David Malcolm wrote: >>>> This patch adds a fix-it hint to various pointer-vs-non-pointer >>>> diagnostics, suggesting the addition of a leading '&' or '*'. >>>> >>>> For example, note the ampersand fix-it hint in the following: >>>> >>>> demo.c:5:22: error: invalid conversion from 'pthread_key_t' {aka >>>> 'unsigned >>>> int'} >>>> to 'pthread_key_t*' {aka 'unsigned int*'} [-fpermissive] >>>> 5 | pthread_key_create(key, NULL); >>>> | ^~~ >>>> | | >>>> | pthread_key_t {aka unsigned int} >>>> | & >>> >>> Having both the type and the fixit underneath the caret looks kind >>> of confusing >> >> I agree it's rather subtle. Keeping the diagnostics separate from >> the suggested fix should avoid the confusion. > > FWIW, the fix-it hint is in a different color (assuming that gcc is > invoked in an environment that prints that...) I figured it would be, but I'm still not sure it's good design to be relying on color alone to distinguish between the problem and the suggested fix. Especially when they are so close to one another and the fix is just a single character with no obvious relationship to the rest of the text on the screen. In other warnings there's at least the "did you forget the '@'?" part to give a clue, even though even there the connection between the "did you forget" and the & several lines down wouldn't necessarily be immediately apparent. I'm not an expert on these things so I'm going strictly by intuition and my personal bias. Are there any user interface guidelines that you like to refer to that speak to this? (Other than our own or the blog post you referenced in one of your posts.) Back in my GUI days, I remember reading articles and even whole books on how to design good interfaces, including layouts and the use of color (e.g., for the color-blind). It seems like there should be something relevant for the command line as well, at least some basic principles that we could apply. Martin