Suggestion for improving #include error message

Greetings Clang people,

My name is Justin and have joined this list about 5 minutes ago.

This afternoon I downloaded LLVM 2.6 and clang as separate bundles.

I'm pleased to say that the build on Linux/Ubuntu went very smoothly.
The documentation explained quite well how to place clang under the LLVM
root/tools directory and that a build of LLVM would pick up tools/clang
and build clang as well.

Great; it worked as advertised and this is a really good start compared
to some other open source projects that have borrowed my time :slight_smile:

Better still my first "hello, clang" .c compile worked just as well though after
first complaining (and rightfully so) about my not #including stdio.h (which I
deliberately initially omitted just to see what error message might surface.)

So after #including stdio.h, clang hello.c faithfully compiled and linked the
classical hello program to a working executable.

Oh, there was another compiler complaint regarding my initial void main() declaring
should be returning an int and I thought "Fair enough, thanks for the very user
friendly error message."

include <stdio.h>

int main()
{
    printf( "Hello, clang\n");
    return 0;
}

So with this as a starting point and reading about how clang desires to produce
friendlier error messages compared to gcc, I wondered what might transpire if the
#include file could not be found (and come to think of it, at this point I had
absolutely no idea what directory, out of my many c/c++ compiler installations,
that clang was actually picking stdio.h up from.)

Accordingly I changed the #include to this:

include <stdioz.h>

and got this

~/workspace/llvm-2.6/jj $ clang hello.c
hello.c:1:10: fatal error: 'stdioz.h' file not found
#include <stdioz.h>

which was quite to be expected but this now prompts my suggestion that it would
be even nicer if clang told me which directories it searched for the unfound
include file "stdioz.h", i.e. if it displayed the include path.

I know this is a really small issue but me thinks little improvements like
this can be really helpful to newcomers, of which I am one.

What do you think?

Regards

Justin Johansson (c/c++ veteran; clang newbie).

Hi Justin,

As you, I'm a clang newbie, but IMHO, it's a bit too much.

The way to search for headers is pretty much standard, even when you
include directories of your own (via -I flag). I think that printing a
list of searched directories and possible matches would not only
clutter the output (console width problems comes to mind) but could
potentially misguide the user of the real problem.

However, there could be a separate tool, to find headers on your
system given your configuration and compilation options, which IDEs
could run upon "file not found" errors. Or maybe a '-vv' mode that
would print lots of warnings, debug information that IDEs could parse
and do intelligent stuff with it.

But making this the default is bad for raw console users. This is easy
for IDEs, but bad for the human eye.

A good example is when you try to get a template class and misplace
the template parameters. G++ will print all the candidates, and when
using std containers the list is horrendously long and wide.

My personal view is that "file not found" is sufficient... :wink:

cheers,
--renato

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm

I'm new to clang too, but as far as I can see clang already has an
option -print-search-dirs that shows the search paths for programs and
libraries.

This could perhaps be extended to show include paths as well? (Or, if
gcc compatibility is an issue, maybe a new option
-print-include-dirs.)

I'm not sure that the #include compiler error needs to be more
informative, but if it should, it could instead mention
-print-search-dirs. That would be less cluttered, but still give a
hint.

//Christian

Christian Adåker wrote:

  

However, there could be a separate tool, to find headers on your
system given your configuration and compilation options, which IDEs
could run upon "file not found" errors. Or maybe a '-vv' mode that
would print lots of warnings, debug information that IDEs could parse
and do intelligent stuff with it.
    
I'm new to clang too, but as far as I can see clang already has an
option -print-search-dirs that shows the search paths for programs and
libraries.

This could perhaps be extended to show include paths as well? (Or, if
gcc compatibility is an issue, maybe a new option
-print-include-dirs.)

I'm not sure that the #include compiler error needs to be more
informative, but if it should, it could instead mention
-print-search-dirs. That would be less cluttered, but still give a
hint.

//Christian

Thanks Renato and Christian for your replies. I missed the
-print-search-dirs option and that is certainly helpful. Christian's
suggestion re hinting -print-search-dirs would be a good idea idea (IMHO);
I don't think that would be too noisy as with missing #include
files there is not much point outputting too many additional compile
errors anyway (?)

cheers, Justin

Christian's
suggestion re hinting -print-search-dirs would be a good idea idea (IMHO);

Agreed that the command line option can make it as verbose as
possible, assuming the user knows what he's doing.

I don't think that would be too noisy as with missing #include
files there is not much point outputting too many additional compile
errors anyway (?)

This is not always the case. On big projects, compilation in multiple
threads or makefiles not stopping at the first error can bring madness
to the output and make it difficult even to know which file is
actually broken.

cheers,
--renato

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm