public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Martin Sebor <msebor@gmail.com>
To: David Malcolm <dmalcolm@redhat.com>, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] RFC: C/C++: print help when a header can't be found
Date: Mon, 12 Nov 2018 21:01:00 -0000	[thread overview]
Message-ID: <57d84cfc-5aeb-5fc1-996e-d1aed976afcf@gmail.com> (raw)
In-Reply-To: <1541979208-37968-1-git-send-email-dmalcolm@redhat.com>

On 11/11/2018 04:33 PM, David Malcolm wrote:
> When gcc can't find a header file, it's a hard error that stops the build,
> typically requiring the user to mess around with compile flags, Makefiles,
> dependencies, and so forth.
>
> Often the exact search paths aren't obvious to the user.  Consider the
> case where the include paths are injected via a tool such as pkg-config,
> such as e.g.:
>
>   gcc $(pkg-config --cflags glib-2.0) demo.c
>
> This patch is an attempt at being more helpful for such cases.  Given that
> the user can't proceed until the issue is resolved, I think it's reasonable
> to default to telling the user as much as possible about what happened.
> This patch list all of the search paths, and any close matches (e.g. for
> misspellings).
>
> Without the patch, the current behavior is:
>
> misspelled-header-1.c:1:10: fatal error: test-header.hpp: No such file or directory
>     1 | #include "test-header.hpp"
>       |          ^~~~~~~~~~~~~~~~~
> compilation terminated.
>
> With the patch, the user gets this output:
>
> misspelled-header-1.c:1:10: fatal error: test-header.hpp: No such file or directory
>     1 | #include "test-header.hpp"
>       |          ^~~~~~~~~~~~~~~~~
> misspelled-header-1.c:1:10: note: paths searched:
> misspelled-header-1.c:1:10: note:  path: ''
> misspelled-header-1.c:1:10: note:   not found: 'test-header.hpp'
> misspelled-header-1.c:1:10: note:   close match: 'test-header.h'
>     1 | #include "test-header.hpp"
>       |          ^~~~~~~~~~~~~~~~~
>       |          "test-header.h"
> misspelled-header-1.c:1:10: note:  path: '/usr/include/glib-2.0' (via '-I')
> misspelled-header-1.c:1:10: note:   not found: '/usr/include/glib-2.0/test-header.hpp'
> misspelled-header-1.c:1:10: note:  path: '/usr/lib64/glib-2.0/include' (via '-I')
> misspelled-header-1.c:1:10: note:   not found: '/usr/lib64/glib-2.0/include/test-header.hpp'
> misspelled-header-1.c:1:10: note:  path: './include' (system directory)
> misspelled-header-1.c:1:10: note:   not found: './include/test-header.hpp'
> misspelled-header-1.c:1:10: note:  path: './include-fixed' (system directory)
> misspelled-header-1.c:1:10: note:   not found: './include-fixed/test-header.hpp'
> misspelled-header-1.c:1:10: note:  path: '/usr/local/include' (system directory)
> misspelled-header-1.c:1:10: note:   not found: '/usr/local/include/test-header.hpp'
> misspelled-header-1.c:1:10: note:  path: '/usr/include' (system directory)
> misspelled-header-1.c:1:10: note:   not found: '/usr/include/test-header.hpp'
> compilation terminated.
>
> showing the paths that were tried, and why (e.g. the -I paths injected by
> the pkg-config invocation), and the .hpp vs .h issue (with a fix-it hint).
>
> It's verbose, but as I said above, the user can't proceed until they
> resolve it, so I think being verbose is appropriate here.
>
> Thoughts?

I think printing the directories and especially the near matches
will be very helpful, especially for big projects with lots of -I
options.

The output could be made substantially shorter, less repetitive,
and so easier to read -- basically cut in half -- by avoiding
most of the duplication and collapsing two notes into one, e.g.
like so:

   fatal error: test-header.hpp: No such file or directory
       1 | #include "test-header.hpp"
         |          ^~~~~~~~~~~~~~~~~
   note: paths searched:
   note: -I '.'
   note:   close match: 'test-header.h'
       1 | #include "test-header.hpp"
         |          ^~~~~~~~~~~~~~~~~
         |          "test-header.h"
   note: -I '/usr/include/glib-2.0'
   note: -I '/usr/lib64/glib-2.0/include'
   note: -isystem './include'
   note: -isystem './include-fixed'
   note: -isystem '/usr/local/include'
   note: -isystem '/usr/include'

or by printing the directories in sections:

   note: -I paths searched:
   note:   '.'
   note:   close match: 'test-header.h'
       1 | #include "test-header.hpp"
         |          ^~~~~~~~~~~~~~~~~
         |          "test-header.h"
   note:   '/usr/include/glib-2.0'
   note:   '/usr/lib64/glib-2.0/include'
   note: -isystem paths searched:
   note:   './include'
   note:   './include-fixed'
   note:   '/usr/local/include'
   note:   '/usr/include'

Martin

  reply	other threads:[~2018-11-12 21:01 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-11 22:46 David Malcolm
2018-11-12 21:01 ` Martin Sebor [this message]
2018-11-13 22:13   ` Jason Merrill
2018-11-16  0:56   ` Eric Gallager

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=57d84cfc-5aeb-5fc1-996e-d1aed976afcf@gmail.com \
    --to=msebor@gmail.com \
    --cc=dmalcolm@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).