head 1.1; branch 1.1.1; access; symbols netbsd-11-0-RC4:1.1.1.4 netbsd-11-0-RC3:1.1.1.4 netbsd-11-0-RC2:1.1.1.4 netbsd-11-0-RC1:1.1.1.4 perseant-exfatfs-base-20250801:1.1.1.4 netbsd-11:1.1.1.4.0.10 netbsd-11-base:1.1.1.4 netbsd-10-1-RELEASE:1.1.1.4 perseant-exfatfs-base-20240630:1.1.1.4 perseant-exfatfs:1.1.1.4.0.8 perseant-exfatfs-base:1.1.1.4 netbsd-8-3-RELEASE:1.1.1.2 netbsd-9-4-RELEASE:1.1.1.3 netbsd-10-0-RELEASE:1.1.1.4 netbsd-10-0-RC6:1.1.1.4 netbsd-10-0-RC5:1.1.1.4 netbsd-10-0-RC4:1.1.1.4 netbsd-10-0-RC3:1.1.1.4 netbsd-10-0-RC2:1.1.1.4 netbsd-10-0-RC1:1.1.1.4 netbsd-10:1.1.1.4.0.6 netbsd-10-base:1.1.1.4 netbsd-9-3-RELEASE:1.1.1.3 cjep_sun2x:1.1.1.4.0.4 cjep_sun2x-base:1.1.1.4 cjep_staticlib_x-base1:1.1.1.4 netbsd-9-2-RELEASE:1.1.1.3 cjep_staticlib_x:1.1.1.4.0.2 cjep_staticlib_x-base:1.1.1.4 netbsd-9-1-RELEASE:1.1.1.3 phil-wifi-20200421:1.1.1.4 phil-wifi-20200411:1.1.1.4 phil-wifi-20200406:1.1.1.4 netbsd-8-2-RELEASE:1.1.1.2 netbsd-9-0-RELEASE:1.1.1.3 netbsd-9-0-RC2:1.1.1.3 netbsd-9-0-RC1:1.1.1.3 netbsd-9:1.1.1.3.0.2 netbsd-9-base:1.1.1.3 phil-wifi-20190609:1.1.1.3 netbsd-8-1-RELEASE:1.1.1.2 netbsd-8-1-RC1:1.1.1.2 pgoyette-compat-merge-20190127:1.1.1.2.28.1 pgoyette-compat-20190127:1.1.1.3 pgoyette-compat-20190118:1.1.1.3 pgoyette-compat-1226:1.1.1.3 pgoyette-compat-1126:1.1.1.3 pgoyette-compat-1020:1.1.1.3 pgoyette-compat-0930:1.1.1.3 pgoyette-compat-0906:1.1.1.3 netbsd-7-2-RELEASE:1.1.1.2 pgoyette-compat-0728:1.1.1.3 clang-337282:1.1.1.3 netbsd-8-0-RELEASE:1.1.1.2 phil-wifi:1.1.1.2.0.30 phil-wifi-base:1.1.1.2 pgoyette-compat-0625:1.1.1.2 netbsd-8-0-RC2:1.1.1.2 pgoyette-compat-0521:1.1.1.2 pgoyette-compat-0502:1.1.1.2 pgoyette-compat-0422:1.1.1.2 netbsd-8-0-RC1:1.1.1.2 pgoyette-compat-0415:1.1.1.2 pgoyette-compat-0407:1.1.1.2 pgoyette-compat-0330:1.1.1.2 pgoyette-compat-0322:1.1.1.2 pgoyette-compat-0315:1.1.1.2 netbsd-7-1-2-RELEASE:1.1.1.2 pgoyette-compat:1.1.1.2.0.28 pgoyette-compat-base:1.1.1.2 netbsd-7-1-1-RELEASE:1.1.1.2 clang-319952:1.1.1.2 matt-nb8-mediatek:1.1.1.2.0.26 matt-nb8-mediatek-base:1.1.1.2 clang-309604:1.1.1.2 perseant-stdc-iso10646:1.1.1.2.0.24 perseant-stdc-iso10646-base:1.1.1.2 netbsd-8:1.1.1.2.0.22 netbsd-8-base:1.1.1.2 prg-localcount2-base3:1.1.1.2 prg-localcount2-base2:1.1.1.2 prg-localcount2-base1:1.1.1.2 prg-localcount2:1.1.1.2.0.20 prg-localcount2-base:1.1.1.2 pgoyette-localcount-20170426:1.1.1.2 bouyer-socketcan-base1:1.1.1.2 pgoyette-localcount-20170320:1.1.1.2 netbsd-7-1:1.1.1.2.0.18 netbsd-7-1-RELEASE:1.1.1.2 netbsd-7-1-RC2:1.1.1.2 clang-294123:1.1.1.2 netbsd-7-nhusb-base-20170116:1.1.1.2 bouyer-socketcan:1.1.1.2.0.16 bouyer-socketcan-base:1.1.1.2 clang-291444:1.1.1.2 pgoyette-localcount-20170107:1.1.1.2 netbsd-7-1-RC1:1.1.1.2 pgoyette-localcount-20161104:1.1.1.2 netbsd-7-0-2-RELEASE:1.1.1.2 localcount-20160914:1.1.1.2 netbsd-7-nhusb:1.1.1.2.0.14 netbsd-7-nhusb-base:1.1.1.2 clang-280599:1.1.1.2 pgoyette-localcount-20160806:1.1.1.2 pgoyette-localcount-20160726:1.1.1.2 pgoyette-localcount:1.1.1.2.0.12 pgoyette-localcount-base:1.1.1.2 netbsd-7-0-1-RELEASE:1.1.1.2 clang-261930:1.1.1.2 netbsd-7-0:1.1.1.2.0.10 netbsd-7-0-RELEASE:1.1.1.2 netbsd-7-0-RC3:1.1.1.2 netbsd-7-0-RC2:1.1.1.2 netbsd-7-0-RC1:1.1.1.2 clang-237755:1.1.1.2 clang-232565:1.1.1.2 clang-227398:1.1.1.2 tls-maxphys-base:1.1.1.2 tls-maxphys:1.1.1.2.0.8 netbsd-7:1.1.1.2.0.6 netbsd-7-base:1.1.1.2 clang-215315:1.1.1.2 clang-209886:1.1.1.2 yamt-pagecache:1.1.1.2.0.4 yamt-pagecache-base9:1.1.1.2 tls-earlyentropy:1.1.1.2.0.2 tls-earlyentropy-base:1.1.1.2 riastradh-xf86-video-intel-2-7-1-pre-2-21-15:1.1.1.2 riastradh-drm2-base3:1.1.1.2 clang-202566:1.1.1.2 clang-201163:1.1.1.2 clang-199312:1.1.1.1 clang-198450:1.1.1.1 clang-196603:1.1.1.1 clang-195771:1.1.1.1 LLVM:1.1.1; locks; strict; comment @# @; 1.1 date 2013.11.28.14.15.01; author joerg; state Exp; branches 1.1.1.1; next ; commitid ow8OybrawrB1f3fx; 1.1.1.1 date 2013.11.28.14.15.01; author joerg; state Exp; branches; next 1.1.1.2; commitid ow8OybrawrB1f3fx; 1.1.1.2 date 2014.02.14.20.07.51; author joerg; state Exp; branches 1.1.1.2.4.1 1.1.1.2.8.1 1.1.1.2.28.1 1.1.1.2.30.1; next 1.1.1.3; commitid annVkZ1sc17rF6px; 1.1.1.3 date 2018.07.17.18.31.56; author joerg; state Exp; branches; next 1.1.1.4; commitid wDzL46ALjrCZgwKA; 1.1.1.4 date 2019.11.13.22.23.15; author joerg; state dead; branches; next ; commitid QD8YATxuNG34YJKB; 1.1.1.2.4.1 date 2014.02.14.20.07.51; author yamt; state dead; branches; next 1.1.1.2.4.2; commitid WSrDtL5nYAUyiyBx; 1.1.1.2.4.2 date 2014.05.22.16.19.50; author yamt; state Exp; branches; next ; commitid WSrDtL5nYAUyiyBx; 1.1.1.2.8.1 date 2014.02.14.20.07.51; author tls; state dead; branches; next 1.1.1.2.8.2; commitid jTnpym9Qu0o4R1Nx; 1.1.1.2.8.2 date 2014.08.19.23.49.30; author tls; state Exp; branches; next ; commitid jTnpym9Qu0o4R1Nx; 1.1.1.2.28.1 date 2018.07.28.04.34.20; author pgoyette; state Exp; branches; next ; commitid 1UP1xAIUxv1ZgRLA; 1.1.1.2.30.1 date 2019.06.10.21.46.49; author christos; state Exp; branches; next 1.1.1.2.30.2; commitid jtc8rnCzWiEEHGqB; 1.1.1.2.30.2 date 2020.04.13.07.50.42; author martin; state dead; branches; next ; commitid X01YhRUPVUDaec4C; desc @@ 1.1 log @Initial revision @ text @ Clang - Expressive Diagnostics

Expressive Diagnostics

In addition to being fast and functional, we aim to make Clang extremely user friendly. As far as a command-line compiler goes, this basically boils down to making the diagnostics (error and warning messages) generated by the compiler be as useful as possible. There are several ways that we do this. This section talks about the experience provided by the command line compiler, contrasting Clang output to GCC 4.2's output in several examples.

Column Numbers and Caret Diagnostics

First, all diagnostics produced by clang include full column number information. The clang command-line compiler driver uses this information to print "point diagnostics". (IDEs can use the information to display in-line error markup.) Precise error location in the source is a feature provided by many commercial compilers, but is generally missing from open source compilers. This is nice because it makes it very easy to understand exactly what is wrong in a particular piece of code

The point (the blue "^" character) exactly shows where the problem is, even inside of a string. This makes it really easy to jump to the problem and helps when multiple instances of the same character occur on a line. (We'll revisit this more in following examples.)

  $ gcc-4.2 -fsyntax-only -Wformat format-strings.c
  format-strings.c:91: warning: too few arguments for format
  $ clang -fsyntax-only format-strings.c
  format-strings.c:91:13: warning: '.*' specified field precision is missing a matching 'int' argument
    printf("%.*d");
              ^

Range Highlighting for Related Text

Clang captures and accurately tracks range information for expressions, statements, and other constructs in your program and uses this to make diagnostics highlight related information. In the following somewhat nonsensical example you can see that you don't even need to see the original source code to understand what is wrong based on the Clang error. Because clang prints a point, you know exactly which plus it is complaining about. The range information highlights the left and right side of the plus which makes it immediately obvious what the compiler is talking about. Range information is very useful for cases involving precedence issues and many other cases.

  $ gcc-4.2 -fsyntax-only t.c
  t.c:7: error: invalid operands to binary + (have 'int' and 'struct A')
  $ clang -fsyntax-only t.c
  t.c:7:39: error: invalid operands to binary expression ('int' and 'struct A')
    return y + func(y ? ((SomeA.X + 40) + SomeA) / 42 + SomeA.X : SomeA.X);
                         ~~~~~~~~~~~~~~ ^ ~~~~~

Precision in Wording

A detail is that we have tried really hard to make the diagnostics that come out of clang contain exactly the pertinent information about what is wrong and why. In the example above, we tell you what the inferred types are for the left and right hand sides, and we don't repeat what is obvious from the point (e.g., that this is a "binary +").

Many other examples abound. In the following example, not only do we tell you that there is a problem with the * and point to it, we say exactly why and tell you what the type is (in case it is a complicated subexpression, such as a call to an overloaded function). This sort of attention to detail makes it much easier to understand and fix problems quickly.

  $ gcc-4.2 -fsyntax-only t.c
  t.c:5: error: invalid type argument of 'unary *'
  $ clang -fsyntax-only t.c
  t.c:5:11: error: indirection requires pointer operand ('int' invalid)
    int y = *SomeA.X;
            ^~~~~~~~

No Pretty Printing of Expressions in Diagnostics

Since Clang has range highlighting, it never needs to pretty print your code back out to you. GCC can produce inscrutible error messages in some cases when it tries to do this. In this example P and Q have type "int*":

  $ gcc-4.2 -fsyntax-only t.c
  #'exact_div_expr' not supported by pp_c_expression#'t.c:12: error: called object  is not a function
  $ clang -fsyntax-only t.c
  t.c:12:8: error: called object type 'int' is not a function or function pointer
    (P-Q)();
    ~~~~~^

This can be particularly bad in G++, which often emits errors containing lowered vtable references. For example:

  $ cat t.cc
  struct a {
    virtual int bar();
  };
  
  struct foo : public virtual a {
  };
  
  void test(foo *P) {
    return P->bar() + *P;
  }
  $ gcc-4.2 t.cc
  t.cc: In function 'void test(foo*)':
  t.cc:9: error: no match for 'operator+' in '(((a*)P) + (*(long int*)(P->foo::<anonymous>.a::_vptr$a + -0x00000000000000020)))->a::bar() + * P'
  t.cc:9: error: return-statement with a value, in function returning 'void'
  $ clang t.cc
  t.cc:9:18: error: invalid operands to binary expression ('int' and 'foo')
    return P->bar() + *P;
           ~~~~~~~~ ^ ~~

Typedef Preservation and Selective Unwrapping

Many programmers use high-level user defined types, typedefs, and other syntactic sugar to refer to types in their program. This is useful because they can abbreviate otherwise very long types and it is useful to preserve the typename in diagnostics. However, sometimes very simple typedefs can wrap trivial types and it is important to strip off the typedef to understand what is going on. Clang aims to handle both cases well.

The following example shows where it is important to preserve a typedef in C. Here the type printed by GCC isn't even valid, but if the error were about a very long and complicated type (as often happens in C++) the error message would be ugly just because it was long and hard to read.

  $ gcc-4.2 -fsyntax-only t.c
  t.c:15: error: invalid operands to binary / (have 'float __vector__' and 'const int *')
  $ clang -fsyntax-only t.c
  t.c:15:11: error: can't convert between vector values of different size ('__m128' and 'int const *')
    myvec[1]/P;
    ~~~~~~~~^~

The following example shows where it is useful for the compiler to expose underlying details of a typedef. If the user was somehow confused about how the system "pid_t" typedef is defined, Clang helpfully displays it with "aka".

  $ gcc-4.2 -fsyntax-only t.c
  t.c:13: error: request for member 'x' in something not a structure or union
  $ clang -fsyntax-only t.c
  t.c:13:9: error: member reference base type 'pid_t' (aka 'int') is not a structure or union
    myvar = myvar.x;
            ~~~~~ ^

In C++, type preservation includes retaining any qualification written into type names. For example, if we take a small snippet of code such as: 

namespace services {
  struct WebService {  };
}
namespace myapp {
  namespace servers {
    struct Server {  };
  }
}

using namespace myapp;
void addHTTPService(servers::Server const &server, ::services::WebService const *http) {
  server += http;
}

and then compile it, we see that Clang is both providing more accurate information and is retaining the types as written by the user (e.g., "servers::Server", "::services::WebService"): 

  $ g++-4.2 -fsyntax-only t.cpp
  t.cpp:9: error: no match for 'operator+=' in 'server += http'
  $ clang -fsyntax-only t.cpp
  t.cpp:9:10: error: invalid operands to binary expression ('servers::Server const' and '::services::WebService const *')
    server += http;
    ~~~~~~ ^  ~~~~

Naturally, type preservation extends to uses of templates, and Clang retains information about how a particular template specialization (like std::vector<Real>) was spelled within the source code. For example:

  $ g++-4.2 -fsyntax-only t.cpp
  t.cpp:12: error: no match for 'operator=' in 'str = vec'
  $ clang -fsyntax-only t.cpp
  t.cpp:12:7: error: incompatible type assigning 'vector<Real>', expected 'std::string' (aka 'class std::basic_string<char>')
    str = vec;
        ^ ~~~

Fix-it Hints

"Fix-it" hints provide advice for fixing small, localized problems in source code. When Clang produces a diagnostic about a particular problem that it can work around (e.g., non-standard or redundant syntax, missing keywords, common mistakes, etc.), it may also provide specific guidance in the form of a code transformation to correct the problem. In the following example, Clang warns about the use of a GCC extension that has been considered obsolete since 1993. The underlined code should be removed, then replaced with the code below the point line (".x =" or ".y =", respectively).

  $ clang t.c
  t.c:5:28: warning: use of GNU old-style field designator extension
  struct point origin = { x: 0.0, y: 0.0 };
                          ~~ ^
                          .x = 
  t.c:5:36: warning: use of GNU old-style field designator extension
  struct point origin = { x: 0.0, y: 0.0 };
                                  ~~ ^
                                  .y =

"Fix-it" hints are most useful for working around common user errors and misconceptions. For example, C++ users commonly forget the syntax for explicit specialization of class templates, as in the error in the following example. Again, after describing the problem, Clang provides the fix--add template<>--as part of the diagnostic.

  $ clang t.cpp
  t.cpp:9:3: error: template specialization requires 'template<>'
    struct iterator_traits<file_iterator> {
    ^
    template<>

Template Type Diffing

Templates types can be long and difficult to read. Moreso when part of an error message. Instead of just printing out the type name, Clang has enough information to remove the common elements and highlight the differences. To show the template structure more clearly, the templated type can also be printed as an indented text tree.

Default: template diff with type elision 
t.cc:4:5: note: candidate function not viable: no known conversion from 'vector<map<[...], float>>' to 'vector<map<[...], double>>' for 1st argument;
-fno-elide-type: template diff without elision 
t.cc:4:5: note: candidate function not viable: no known conversion from 'vector<map<int, float>>' to 'vector<map<int, double>>' for 1st argument;
-fdiagnostics-show-template-tree: template tree printing with elision 
t.cc:4:5: note: candidate function not viable: no known conversion for 1st argument;
  vector<
    map<
      [...], 
      [float != double]>>
-fdiagnostics-show-template-tree -fno-elide-type: template tree printing with no elision 
t.cc:4:5: note:M candidate function not viable: no known conversion for 1st argument;
  vector<
    map<
      int, 
      [float != double]>>

Automatic Macro Expansion

Many errors happen in macros that are sometimes deeply nested. With traditional compilers, you need to dig deep into the definition of the macro to understand how you got into trouble. The following simple example shows how Clang helps you out by automatically printing instantiation information and nested range information for diagnostics as they are instantiated through macros and also shows how some of the other pieces work in a bigger example.

  $ gcc-4.2 -fsyntax-only t.c
  t.c: In function 'test':
  t.c:80: error: invalid operands to binary < (have 'struct mystruct' and 'float')
  $ clang -fsyntax-only t.c
  t.c:80:3: error: invalid operands to binary expression ('typeof(P)' (aka 'struct mystruct') and 'typeof(F)' (aka 'float'))
    X = MYMAX(P, F);
        ^~~~~~~~~~~
  t.c:76:94: note: expanded from:
  #define MYMAX(A,B)    __extension__ ({ __typeof__(A) __a = (A); __typeof__(B) __b = (B); __a < __b ? __b : __a; })
                                                                                           ~~~ ^ ~~~

Here's another real world warning that occurs in the "window" Unix package (which implements the "wwopen" class of APIs):

  $ clang -fsyntax-only t.c
  t.c:22:2: warning: type specifier missing, defaults to 'int'
          ILPAD();
          ^
  t.c:17:17: note: expanded from:
  #define ILPAD() PAD((NROW - tt.tt_row) * 10)    /* 1 ms per char */
                  ^
  t.c:14:2: note: expanded from:
          register i; \
          ^

In practice, we've found that Clang's treatment of macros is actually more useful in multiply nested macros that in simple ones.

Quality of Implementation and Attention to Detail

Finally, we have put a lot of work polishing the little things, because little things add up over time and contribute to a great user experience.

The following example shows a trivial little tweak, where we tell you to put the semicolon at the end of the line that is missing it (line 4) instead of at the beginning of the following line (line 5). This is particularly important with fixit hints and point diagnostics, because otherwise you don't get the important context. 

  $ gcc-4.2 t.c
  t.c: In function 'foo':
  t.c:5: error: expected ';' before '}' token
  $ clang t.c
  t.c:4:8: error: expected ';' after expression
    bar()
         ^
         ;

The following example shows much better error recovery than GCC. The message coming out of GCC is completely useless for diagnosing the problem. Clang tries much harder and produces a much more useful diagnosis of the problem.

  $ gcc-4.2 t.c
  t.c:3: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
  $ clang t.c
  t.c:3:1: error: unknown type name 'foo_t'
  foo_t *P = 0;
  ^

The following example shows that we recover from the simple case of forgetting a ; after a struct definition much better than GCC.

  $ cat t.cc
  template<class T>
  class a {}
  class temp {};
  a<temp> b;
  struct b {
  }
  $ gcc-4.2 t.cc
  t.cc:3: error: multiple types in one declaration
  t.cc:4: error: non-template type 'a' used as a template
  t.cc:4: error: invalid type in declaration before ';' token
  t.cc:6: error: expected unqualified-id at end of input
  $ clang t.cc
  t.cc:2:11: error: expected ';' after class
  class a {}
            ^
            ;
  t.cc:6:2: error: expected ';' after struct
  }
   ^
   ;

While each of these details is minor, we feel that they all add up to provide a much more polished experience.

@ 1.1.1.1 log @Import Clang 3.4rc1 r195771. @ text @@ 1.1.1.2 log @Import Clang 3.5svn r201163. @ text @d10 4 a13 8 .loc { font-weight: bold; } .err { color:red; font-weight: bold; } .warn { color:magenta; font-weight: bold; } .note { color:gray; font-weight: bold; } .msg { font-weight: bold; } .cmd { font-style: italic; } .snip { } .point { color:green; font-weight: bold; } d32 4 a35 1 Clang output to GCC 4.9's output in some cases. d44 4 a47 2 This is nice because it makes it very easy to understand exactly what is wrong in a particular piece of code.

d49 1 a49 1

The point (the green "^" character) exactly shows where the problem is, even d51 1 a51 1 helps when multiple instances of the same character occur on a line. (We'll d55 5 a59 9 $ gcc-4.9 -fsyntax-only -Wformat format-strings.c format-strings.c: In function 'void f()': format-strings.c:91:16: warning: field precision specifier '.*' expects a matching 'int' argument [-Wformat=] printf("%.*d"); ^ format-strings.c:91:16: warning: format '%d' expects a matching 'int' argument [-Wformat=] $ clang -fsyntax-only format-strings.c format-strings.c:91:13: warning: '.*' specified field precision is missing a matching 'int' argument printf("%.*d"); a62 8

Note that modern versions of GCC have followed Clang's lead, and are now able to give a column for a diagnostic, and include a snippet of source text in the result. However, Clang's column number is much more accurate, pointing at the problematic format specifier, rather than the ) character the parser had reached when the problem was detected. Also, Clang's diagnostic is colored by default, making it easier to distinguish from nearby text.

d77 5 a81 8 $ gcc-4.9 -fsyntax-only t.c t.c: In function 'int f(int, int)': t.c:7:39: error: invalid operands to binary + (have 'int' and 'struct A') return y + func(y ? ((SomeA.X + 40) + SomeA) / 42 + SomeA.X : SomeA.X); ^ $ clang -fsyntax-only t.c t.c:7:39: error: invalid operands to binary expression ('int' and 'struct A') return y + func(y ? ((SomeA.X + 40) + SomeA) / 42 + SomeA.X : SomeA.X); d93 1 a93 2

Many other examples abound. In the following example, not only do we tell you that there is a problem with the * d100 5 a104 7 $ gcc-4.9 -fsyntax-only t.c t.c:5:11: error: invalid type argument of unary '*' (have 'int') return *SomeA.X; ^ $ clang -fsyntax-only t.c t.c:5:11: error: indirection requires pointer operand ('int' invalid) int y = *SomeA.X; d108 41 d159 3 a161 1 a typedef in C.

d164 4 a167 2 $ clang -fsyntax-only t.c t.c:15:11: error: can't convert between vector values of different size ('__m128' and 'int const *') d177 4 a180 2 $ clang -fsyntax-only t.c t.c:13:9: error: member reference base type 'pid_t' (aka 'int') is not a structure or union d205 1 a205 1

and then compile it, we see that Clang is both providing accurate information and is retaining the types as written by the user (e.g., "servers::Server", "::services::WebService"): d208 4 a211 2 $ clang -fsyntax-only t.cpp t.cpp:9:10: error: invalid operands to binary expression ('servers::Server const' and '::services::WebService const *') d219 4 a222 2 $ clang -fsyntax-only t.cpp t.cpp:12:7: error: incompatible type assigning 'vector<Real>', expected 'std::string' (aka 'class std::basic_string<char>') d240 2 a241 2 $ clang t.c t.c:5:28: warning: use of GNU old-style field designator extension d243 1 a243 1 ~~ ^ d245 1 a245 1 t.c:5:36: warning: use of GNU old-style field designator extension d247 1 a247 1 ~~ ^ d259 2 a260 2 $ clang t.cpp t.cpp:9:3: error: template specialization requires 'template<>' d276 1 a276 1 t.cc:4:5: note: candidate function not viable: no known conversion from 'vector<map<[...], float>>' to 'vector<map<[...], double>>' for 1st argument; d280 1 a280 1 t.cc:4:5: note: candidate function not viable: no known conversion from 'vector<map<int, float>>' to 'vector<map<int, double>>' for 1st argument; d284 1 a284 1 t.cc:4:5: note: candidate function not viable: no known conversion for 1st argument; d292 1 a292 1 t.cc:4:5: note: candidate function not viable: no known conversion for 1st argument; d309 5 a313 2 $ clang -fsyntax-only t.c t.c:80:3: error: invalid operands to binary expression ('typeof(P)' (aka 'struct mystruct') and 'typeof(F)' (aka 'float')) d316 1 a316 1 t.c:76:94: note: expanded from: d325 2 a326 2 $ clang -fsyntax-only t.c t.c:22:2: warning: type specifier missing, defaults to 'int' d329 1 a329 1 t.c:17:17: note: expanded from: d332 1 a332 1 t.c:14:2: note: expanded from: d345 30 d379 1 a379 1 $ cat t.cc d381 4 a384 26 class a {}; struct b {} a<int> c; $ gcc-4.9 t.cc t.cc:4:8: error: invalid declarator before 'c' a<int> c; ^ $ clang t.cc t.cc:3:12: error: expected ';' after struct struct b {} ^ ;

The following example shows that we diagnose and recover from a missing typename keyword well, even in complex circumstances where GCC cannot cope.

  $ cat t.cc
  template<class T> void f(T::type) { }
  struct A { };
  void g()
  {
      A a;
      f<A>(a);
d386 14
a399 22
  $ gcc-4.9 t.cc
  t.cc:1:33: error: variable or field 'f' declared void
   template<class T> void f(T::type) { }
                                   ^
  t.cc: In function 'void g()':
  t.cc:6:5: error: 'f' was not declared in this scope
       f<A>(a);
       ^
  t.cc:6:8: error: expected primary-expression before '>' token
       f<A>(a);
          ^
  $ clang t.cc
  t.cc:1:26: error: missing 'typename' prior to dependent type name 'T::type'
  template<class T> void f(T::type) { }
                           ^~~~~~~
                           typename 
  t.cc:6:5: error: no matching function for call to 'f'
      f<A>(a);
      ^~~~
  t.cc:1:24: note: candidate template ignored: substitution failure [with T = A]: no type named 'type' in 'A'
  template<class T> void f(T::type) { }
                         ^    ~~~~
a401 2


@


1.1.1.2.30.1
log
@Sync with HEAD
@
text
@d234 1
a234 1

Templates types can be long and difficult to read.  More so when part of an
@


1.1.1.2.30.2
log
@Mostly merge changes from HEAD upto 20200411
@
text
@@


1.1.1.2.28.1
log
@Sync with HEAD
@
text
@d234 1
a234 1

Templates types can be long and difficult to read.  More so when part of an
@


1.1.1.3
log
@Import clang r337282 from trunk
@
text
@d234 1
a234 1

Templates types can be long and difficult to read.  More so when part of an
@


1.1.1.4
log
@Mark old LLVM instance as dead.
@
text
@@


1.1.1.2.8.1
log
@file diagnostics.html was added on branch tls-maxphys on 2014-08-19 23:49:30 +0000
@
text
@d1 372
@


1.1.1.2.8.2
log
@Rebase to HEAD as of a few days ago.
@
text
@a0 372



  
  Clang - Expressive Diagnostics
  
  
  











Expressive Diagnostics




In addition to being fast and functional, we aim to make Clang extremely user
friendly.  As far as a command-line compiler goes, this basically boils down to
making the diagnostics (error and warning messages) generated by the compiler
be as useful as possible.  There are several ways that we do this.  This section
talks about the experience provided by the command line compiler, contrasting
Clang output to GCC 4.9's output in some cases.




Column Numbers and Caret Diagnostics



First, all diagnostics produced by clang include full column number
information. The clang command-line compiler driver uses this information
to print "point diagnostics".
(IDEs can use the information to display in-line error markup.)
This is nice because it makes it very easy to understand exactly
what is wrong in a particular piece of code.



The point (the green "^" character) exactly shows where the problem is, even
inside of a string.  This makes it really easy to jump to the problem and
helps when multiple instances of the same character occur on a line. (We'll
revisit this more in following examples.)



  $ gcc-4.9 -fsyntax-only -Wformat format-strings.c
  format-strings.c: In function 'void f()':
  format-strings.c:91:16: warning: field precision specifier '.*' expects a matching 'int' argument [-Wformat=]
     printf("%.*d");
                  ^
  format-strings.c:91:16: warning: format '%d' expects a matching 'int' argument [-Wformat=]
  $ clang -fsyntax-only format-strings.c
  format-strings.c:91:13: warning: '.*' specified field precision is missing a matching 'int' argument
    printf("%.*d");
              ^




Note that modern versions of GCC have followed Clang's lead, and are
now able to give a column for a diagnostic, and include a snippet of source
text in the result. However, Clang's column number is much more accurate,
pointing at the problematic format specifier, rather than the )
character the parser had reached when the problem was detected.
Also, Clang's diagnostic is colored by default, making it easier to
distinguish from nearby text.



Range Highlighting for Related Text



Clang captures and accurately tracks range information for expressions,
statements, and other constructs in your program and uses this to make
diagnostics highlight related information.  In the following somewhat
nonsensical example you can see that you don't even need to see the original source code to
understand what is wrong based on the Clang error. Because clang prints a
point, you know exactly which plus it is complaining about.  The range
information highlights the left and right side of the plus which makes it
immediately obvious what the compiler is talking about.
Range information is very useful for
cases involving precedence issues and many other cases.



  $ gcc-4.9 -fsyntax-only t.c
  t.c: In function 'int f(int, int)':
  t.c:7:39: error: invalid operands to binary + (have 'int' and 'struct A')
     return y + func(y ? ((SomeA.X + 40) + SomeA) / 42 + SomeA.X : SomeA.X);
                                         ^
  $ clang -fsyntax-only t.c
  t.c:7:39: error: invalid operands to binary expression ('int' and 'struct A')
    return y + func(y ? ((SomeA.X + 40) + SomeA) / 42 + SomeA.X : SomeA.X);
                         ~~~~~~~~~~~~~~ ^ ~~~~~




Precision in Wording



A detail is that we have tried really hard to make the diagnostics that come
out of clang contain exactly the pertinent information about what is wrong and
why.  In the example above, we tell you what the inferred types are for
the left and right hand sides, and we don't repeat what is obvious from the
point (e.g., that this is a "binary +").



Many other examples abound. In the following example, not only do we tell you
that there is a problem with the *
and point to it, we say exactly why and tell you what the type is (in case it is
a complicated subexpression, such as a call to an overloaded function).  This
sort of attention to detail makes it much easier to understand and fix problems
quickly.



  $ gcc-4.9 -fsyntax-only t.c
  t.c:5:11: error: invalid type argument of unary '*' (have 'int')
    return *SomeA.X;
           ^
  $ clang -fsyntax-only t.c
  t.c:5:11: error: indirection requires pointer operand ('int' invalid)
    int y = *SomeA.X;
            ^~~~~~~~




Typedef Preservation and Selective Unwrapping



Many programmers use high-level user defined types, typedefs, and other
syntactic sugar to refer to types in their program.  This is useful because they
can abbreviate otherwise very long types and it is useful to preserve the
typename in diagnostics.  However, sometimes very simple typedefs can wrap
trivial types and it is important to strip off the typedef to understand what
is going on.  Clang aims to handle both cases well.



The following example shows where it is important to preserve
a typedef in C.



  $ clang -fsyntax-only t.c
  t.c:15:11: error: can't convert between vector values of different size ('__m128' and 'int const *')
    myvec[1]/P;
    ~~~~~~~~^~




The following example shows where it is useful for the compiler to expose
underlying details of a typedef. If the user was somehow confused about how the
system "pid_t" typedef is defined, Clang helpfully displays it with "aka".



  $ clang -fsyntax-only t.c
  t.c:13:9: error: member reference base type 'pid_t' (aka 'int') is not a structure or union
    myvar = myvar.x;
            ~~~~~ ^




In C++, type preservation includes retaining any qualification written into type names. For example, if we take a small snippet of code such as:




namespace services {
  struct WebService {  };
}
namespace myapp {
  namespace servers {
    struct Server {  };
  }
}

using namespace myapp;
void addHTTPService(servers::Server const &server, ::services::WebService const *http) {
  server += http;
}






and then compile it, we see that Clang is both providing accurate information and is retaining the types as written by the user (e.g., "servers::Server", "::services::WebService"):


  $ clang -fsyntax-only t.cpp
  t.cpp:9:10: error: invalid operands to binary expression ('servers::Server const' and '::services::WebService const *')
    server += http;
    ~~~~~~ ^  ~~~~




Naturally, type preservation extends to uses of templates, and Clang retains information about how a particular template specialization (like std::vector<Real>) was spelled within the source code. For example:



  $ clang -fsyntax-only t.cpp
  t.cpp:12:7: error: incompatible type assigning 'vector<Real>', expected 'std::string' (aka 'class std::basic_string<char>')
    str = vec;
        ^ ~~~




Fix-it Hints



"Fix-it" hints provide advice for fixing small, localized problems
in source code. When Clang produces a diagnostic about a particular
problem that it can work around (e.g., non-standard or redundant
syntax, missing keywords, common mistakes, etc.), it may also provide
specific guidance in the form of a code transformation to correct the
problem. In the following example, Clang warns about the use of a GCC
extension that has been considered obsolete since 1993. The underlined
code should be removed, then replaced with the code below the
point line (".x =" or ".y =", respectively).



  $ clang t.c
  t.c:5:28: warning: use of GNU old-style field designator extension
  struct point origin = { x: 0.0, y: 0.0 };
                          ~~ ^
                          .x = 
  t.c:5:36: warning: use of GNU old-style field designator extension
  struct point origin = { x: 0.0, y: 0.0 };
                                  ~~ ^
                                  .y = 




"Fix-it" hints are most useful for
working around common user errors and misconceptions. For example, C++ users
commonly forget the syntax for explicit specialization of class templates,
as in the error in the following example. Again, after describing the problem,
Clang provides the fix--add template<>--as part of the
diagnostic.



  $ clang t.cpp
  t.cpp:9:3: error: template specialization requires 'template<>'
    struct iterator_traits<file_iterator> {
    ^
    template<> 




Template Type Diffing



Templates types can be long and difficult to read.  Moreso when part of an
error message.  Instead of just printing out the type name, Clang has enough
information to remove the common elements and highlight the differences.  To
show the template structure more clearly, the templated type can also be
printed as an indented text tree.


Default: template diff with type elision

t.cc:4:5: note: candidate function not viable: no known conversion from 'vector<map<[...], float>>' to 'vector<map<[...], double>>' for 1st argument;


-fno-elide-type: template diff without elision

t.cc:4:5: note: candidate function not viable: no known conversion from 'vector<map<int, float>>' to 'vector<map<int, double>>' for 1st argument;


-fdiagnostics-show-template-tree: template tree printing with elision

t.cc:4:5: note: candidate function not viable: no known conversion for 1st argument;
  vector<
    map<
      [...], 
      [float != double]>>


-fdiagnostics-show-template-tree -fno-elide-type: template tree printing with no elision

t.cc:4:5: note: candidate function not viable: no known conversion for 1st argument;
  vector<
    map<
      int, 
      [float != double]>>




Automatic Macro Expansion



Many errors happen in macros that are sometimes deeply nested.  With
traditional compilers, you need to dig deep into the definition of the macro to
understand how you got into trouble.  The following simple example shows how
Clang helps you out by automatically printing instantiation information and
nested range information for diagnostics as they are instantiated through macros
and also shows how some of the other pieces work in a bigger example.



  $ clang -fsyntax-only t.c
  t.c:80:3: error: invalid operands to binary expression ('typeof(P)' (aka 'struct mystruct') and 'typeof(F)' (aka 'float'))
    X = MYMAX(P, F);
        ^~~~~~~~~~~
  t.c:76:94: note: expanded from:
  #define MYMAX(A,B)    __extension__ ({ __typeof__(A) __a = (A); __typeof__(B) __b = (B); __a < __b ? __b : __a; })
                                                                                           ~~~ ^ ~~~




Here's another real world warning that occurs in the "window" Unix package (which
implements the "wwopen" class of APIs):



  $ clang -fsyntax-only t.c
  t.c:22:2: warning: type specifier missing, defaults to 'int'
          ILPAD();
          ^
  t.c:17:17: note: expanded from:
  #define ILPAD() PAD((NROW - tt.tt_row) * 10)    /* 1 ms per char */
                  ^
  t.c:14:2: note: expanded from:
          register i; \
          ^




In practice, we've found that Clang's treatment of macros is actually more useful in multiply nested
macros that in simple ones.



Quality of Implementation and Attention to Detail



Finally, we have put a lot of work polishing the little things, because
little things add up over time and contribute to a great user experience.



The following example shows that we recover from the simple case of
forgetting a ; after a struct definition much better than GCC.



  $ cat t.cc
  template<class T>
  class a {};
  struct b {}
  a<int> c;
  $ gcc-4.9 t.cc
  t.cc:4:8: error: invalid declarator before 'c'
   a<int> c;
           ^
  $ clang t.cc
  t.cc:3:12: error: expected ';' after struct
  struct b {}
             ^
             ;




The following example shows that we diagnose and recover from a missing
typename keyword well, even in complex circumstances where GCC
cannot cope.



  $ cat t.cc
  template<class T> void f(T::type) { }
  struct A { };
  void g()
  {
      A a;
      f<A>(a);
  }
  $ gcc-4.9 t.cc
  t.cc:1:33: error: variable or field 'f' declared void
   template<class T> void f(T::type) { }
                                   ^
  t.cc: In function 'void g()':
  t.cc:6:5: error: 'f' was not declared in this scope
       f<A>(a);
       ^
  t.cc:6:8: error: expected primary-expression before '>' token
       f<A>(a);
          ^
  $ clang t.cc
  t.cc:1:26: error: missing 'typename' prior to dependent type name 'T::type'
  template<class T> void f(T::type) { }
                           ^~~~~~~
                           typename 
  t.cc:6:5: error: no matching function for call to 'f'
      f<A>(a);
      ^~~~
  t.cc:1:24: note: candidate template ignored: substitution failure [with T = A]: no type named 'type' in 'A'
  template<class T> void f(T::type) { }
                         ^    ~~~~






While each of these details is minor, we feel that they all add up to provide
a much more polished experience.






@


1.1.1.2.4.1
log
@file diagnostics.html was added on branch yamt-pagecache on 2014-05-22 16:19:50 +0000
@
text
@d1 372
@


1.1.1.2.4.2
log
@sync with head.

for a reference, the tree before this commit was tagged
as yamt-pagecache-tag8.

this commit was splitted into small chunks to avoid
a limitation of cvs.  ("Protocol error: too many arguments")
@
text
@a0 372



  
  Clang - Expressive Diagnostics
  
  
  











Expressive Diagnostics




In addition to being fast and functional, we aim to make Clang extremely user
friendly.  As far as a command-line compiler goes, this basically boils down to
making the diagnostics (error and warning messages) generated by the compiler
be as useful as possible.  There are several ways that we do this.  This section
talks about the experience provided by the command line compiler, contrasting
Clang output to GCC 4.9's output in some cases.




Column Numbers and Caret Diagnostics



First, all diagnostics produced by clang include full column number
information. The clang command-line compiler driver uses this information
to print "point diagnostics".
(IDEs can use the information to display in-line error markup.)
This is nice because it makes it very easy to understand exactly
what is wrong in a particular piece of code.



The point (the green "^" character) exactly shows where the problem is, even
inside of a string.  This makes it really easy to jump to the problem and
helps when multiple instances of the same character occur on a line. (We'll
revisit this more in following examples.)



  $ gcc-4.9 -fsyntax-only -Wformat format-strings.c
  format-strings.c: In function 'void f()':
  format-strings.c:91:16: warning: field precision specifier '.*' expects a matching 'int' argument [-Wformat=]
     printf("%.*d");
                  ^
  format-strings.c:91:16: warning: format '%d' expects a matching 'int' argument [-Wformat=]
  $ clang -fsyntax-only format-strings.c
  format-strings.c:91:13: warning: '.*' specified field precision is missing a matching 'int' argument
    printf("%.*d");
              ^




Note that modern versions of GCC have followed Clang's lead, and are
now able to give a column for a diagnostic, and include a snippet of source
text in the result. However, Clang's column number is much more accurate,
pointing at the problematic format specifier, rather than the )
character the parser had reached when the problem was detected.
Also, Clang's diagnostic is colored by default, making it easier to
distinguish from nearby text.



Range Highlighting for Related Text



Clang captures and accurately tracks range information for expressions,
statements, and other constructs in your program and uses this to make
diagnostics highlight related information.  In the following somewhat
nonsensical example you can see that you don't even need to see the original source code to
understand what is wrong based on the Clang error. Because clang prints a
point, you know exactly which plus it is complaining about.  The range
information highlights the left and right side of the plus which makes it
immediately obvious what the compiler is talking about.
Range information is very useful for
cases involving precedence issues and many other cases.



  $ gcc-4.9 -fsyntax-only t.c
  t.c: In function 'int f(int, int)':
  t.c:7:39: error: invalid operands to binary + (have 'int' and 'struct A')
     return y + func(y ? ((SomeA.X + 40) + SomeA) / 42 + SomeA.X : SomeA.X);
                                         ^
  $ clang -fsyntax-only t.c
  t.c:7:39: error: invalid operands to binary expression ('int' and 'struct A')
    return y + func(y ? ((SomeA.X + 40) + SomeA) / 42 + SomeA.X : SomeA.X);
                         ~~~~~~~~~~~~~~ ^ ~~~~~




Precision in Wording



A detail is that we have tried really hard to make the diagnostics that come
out of clang contain exactly the pertinent information about what is wrong and
why.  In the example above, we tell you what the inferred types are for
the left and right hand sides, and we don't repeat what is obvious from the
point (e.g., that this is a "binary +").



Many other examples abound. In the following example, not only do we tell you
that there is a problem with the *
and point to it, we say exactly why and tell you what the type is (in case it is
a complicated subexpression, such as a call to an overloaded function).  This
sort of attention to detail makes it much easier to understand and fix problems
quickly.



  $ gcc-4.9 -fsyntax-only t.c
  t.c:5:11: error: invalid type argument of unary '*' (have 'int')
    return *SomeA.X;
           ^
  $ clang -fsyntax-only t.c
  t.c:5:11: error: indirection requires pointer operand ('int' invalid)
    int y = *SomeA.X;
            ^~~~~~~~




Typedef Preservation and Selective Unwrapping



Many programmers use high-level user defined types, typedefs, and other
syntactic sugar to refer to types in their program.  This is useful because they
can abbreviate otherwise very long types and it is useful to preserve the
typename in diagnostics.  However, sometimes very simple typedefs can wrap
trivial types and it is important to strip off the typedef to understand what
is going on.  Clang aims to handle both cases well.



The following example shows where it is important to preserve
a typedef in C.



  $ clang -fsyntax-only t.c
  t.c:15:11: error: can't convert between vector values of different size ('__m128' and 'int const *')
    myvec[1]/P;
    ~~~~~~~~^~




The following example shows where it is useful for the compiler to expose
underlying details of a typedef. If the user was somehow confused about how the
system "pid_t" typedef is defined, Clang helpfully displays it with "aka".



  $ clang -fsyntax-only t.c
  t.c:13:9: error: member reference base type 'pid_t' (aka 'int') is not a structure or union
    myvar = myvar.x;
            ~~~~~ ^




In C++, type preservation includes retaining any qualification written into type names. For example, if we take a small snippet of code such as:




namespace services {
  struct WebService {  };
}
namespace myapp {
  namespace servers {
    struct Server {  };
  }
}

using namespace myapp;
void addHTTPService(servers::Server const &server, ::services::WebService const *http) {
  server += http;
}






and then compile it, we see that Clang is both providing accurate information and is retaining the types as written by the user (e.g., "servers::Server", "::services::WebService"):


  $ clang -fsyntax-only t.cpp
  t.cpp:9:10: error: invalid operands to binary expression ('servers::Server const' and '::services::WebService const *')
    server += http;
    ~~~~~~ ^  ~~~~




Naturally, type preservation extends to uses of templates, and Clang retains information about how a particular template specialization (like std::vector<Real>) was spelled within the source code. For example:



  $ clang -fsyntax-only t.cpp
  t.cpp:12:7: error: incompatible type assigning 'vector<Real>', expected 'std::string' (aka 'class std::basic_string<char>')
    str = vec;
        ^ ~~~




Fix-it Hints



"Fix-it" hints provide advice for fixing small, localized problems
in source code. When Clang produces a diagnostic about a particular
problem that it can work around (e.g., non-standard or redundant
syntax, missing keywords, common mistakes, etc.), it may also provide
specific guidance in the form of a code transformation to correct the
problem. In the following example, Clang warns about the use of a GCC
extension that has been considered obsolete since 1993. The underlined
code should be removed, then replaced with the code below the
point line (".x =" or ".y =", respectively).



  $ clang t.c
  t.c:5:28: warning: use of GNU old-style field designator extension
  struct point origin = { x: 0.0, y: 0.0 };
                          ~~ ^
                          .x = 
  t.c:5:36: warning: use of GNU old-style field designator extension
  struct point origin = { x: 0.0, y: 0.0 };
                                  ~~ ^
                                  .y = 




"Fix-it" hints are most useful for
working around common user errors and misconceptions. For example, C++ users
commonly forget the syntax for explicit specialization of class templates,
as in the error in the following example. Again, after describing the problem,
Clang provides the fix--add template<>--as part of the
diagnostic.



  $ clang t.cpp
  t.cpp:9:3: error: template specialization requires 'template<>'
    struct iterator_traits<file_iterator> {
    ^
    template<> 




Template Type Diffing



Templates types can be long and difficult to read.  Moreso when part of an
error message.  Instead of just printing out the type name, Clang has enough
information to remove the common elements and highlight the differences.  To
show the template structure more clearly, the templated type can also be
printed as an indented text tree.


Default: template diff with type elision

t.cc:4:5: note: candidate function not viable: no known conversion from 'vector<map<[...], float>>' to 'vector<map<[...], double>>' for 1st argument;


-fno-elide-type: template diff without elision

t.cc:4:5: note: candidate function not viable: no known conversion from 'vector<map<int, float>>' to 'vector<map<int, double>>' for 1st argument;


-fdiagnostics-show-template-tree: template tree printing with elision

t.cc:4:5: note: candidate function not viable: no known conversion for 1st argument;
  vector<
    map<
      [...], 
      [float != double]>>


-fdiagnostics-show-template-tree -fno-elide-type: template tree printing with no elision

t.cc:4:5: note: candidate function not viable: no known conversion for 1st argument;
  vector<
    map<
      int, 
      [float != double]>>




Automatic Macro Expansion



Many errors happen in macros that are sometimes deeply nested.  With
traditional compilers, you need to dig deep into the definition of the macro to
understand how you got into trouble.  The following simple example shows how
Clang helps you out by automatically printing instantiation information and
nested range information for diagnostics as they are instantiated through macros
and also shows how some of the other pieces work in a bigger example.



  $ clang -fsyntax-only t.c
  t.c:80:3: error: invalid operands to binary expression ('typeof(P)' (aka 'struct mystruct') and 'typeof(F)' (aka 'float'))
    X = MYMAX(P, F);
        ^~~~~~~~~~~
  t.c:76:94: note: expanded from:
  #define MYMAX(A,B)    __extension__ ({ __typeof__(A) __a = (A); __typeof__(B) __b = (B); __a < __b ? __b : __a; })
                                                                                           ~~~ ^ ~~~




Here's another real world warning that occurs in the "window" Unix package (which
implements the "wwopen" class of APIs):



  $ clang -fsyntax-only t.c
  t.c:22:2: warning: type specifier missing, defaults to 'int'
          ILPAD();
          ^
  t.c:17:17: note: expanded from:
  #define ILPAD() PAD((NROW - tt.tt_row) * 10)    /* 1 ms per char */
                  ^
  t.c:14:2: note: expanded from:
          register i; \
          ^




In practice, we've found that Clang's treatment of macros is actually more useful in multiply nested
macros that in simple ones.



Quality of Implementation and Attention to Detail



Finally, we have put a lot of work polishing the little things, because
little things add up over time and contribute to a great user experience.



The following example shows that we recover from the simple case of
forgetting a ; after a struct definition much better than GCC.



  $ cat t.cc
  template<class T>
  class a {};
  struct b {}
  a<int> c;
  $ gcc-4.9 t.cc
  t.cc:4:8: error: invalid declarator before 'c'
   a<int> c;
           ^
  $ clang t.cc
  t.cc:3:12: error: expected ';' after struct
  struct b {}
             ^
             ;




The following example shows that we diagnose and recover from a missing
typename keyword well, even in complex circumstances where GCC
cannot cope.



  $ cat t.cc
  template<class T> void f(T::type) { }
  struct A { };
  void g()
  {
      A a;
      f<A>(a);
  }
  $ gcc-4.9 t.cc
  t.cc:1:33: error: variable or field 'f' declared void
   template<class T> void f(T::type) { }
                                   ^
  t.cc: In function 'void g()':
  t.cc:6:5: error: 'f' was not declared in this scope
       f<A>(a);
       ^
  t.cc:6:8: error: expected primary-expression before '>' token
       f<A>(a);
          ^
  $ clang t.cc
  t.cc:1:26: error: missing 'typename' prior to dependent type name 'T::type'
  template<class T> void f(T::type) { }
                           ^~~~~~~
                           typename 
  t.cc:6:5: error: no matching function for call to 'f'
      f<A>(a);
      ^~~~
  t.cc:1:24: note: candidate template ignored: substitution failure [with T = A]: no type named 'type' in 'A'
  template<class T> void f(T::type) { }
                         ^    ~~~~






While each of these details is minor, we feel that they all add up to provide
a much more polished experience.






@