Each point below is a mini-project on itself. Please ask in gcc@gcc.gnu.org for more information or you want to help to implement some of these projects.

A) Printing the input expression instead of re-constructing it. This will fix the well-known limitation of the pretty-printer (see PR3544[123], PR35742, PR49152 and etc.). This requires:

  1. For each preprocessed token, we would need to keep two locations: one for the preprocessed location and another for the original location. [FIXED in GCC 4.7 with -ftrack-macro-expansion]

  2. For non-preprocessed expr we need at least two locations per expr (beg/end). This requires:
    1. Changes on the build_* functions to handle multiple locations.

    2. Track the end of tokens:

                 X + some_long\
           _ident??/
           ifier
      We need to track the locations of X and r somehow.

  3. Changes in the parser to pass down the correct locations to the build_* functions.

  4. A location(s) -> source strings interface and machinery. Ideally, this should be more or less independent of CPP, so CPP (through the diagnostics machinery) calls into this when needed and not the other way around. This can be implemented in several ways:

    1. Keeping the CPP buffers in memory and having in line-maps pointers directly into the buffers contents. This is easy and fast but potentially memory consuming. Care to handle charsets, tabs, etc must be taken into account. Factoring out anything useful from libcpp would help to implement this.

    2. Re-open the file and fseek. This is not trivial since we need to do it fast but still do all character conversions that we did when libcpp opened it the first time. This is approximately what Clang (LLVM) does and it seems they can do it very fast by keeping a cache of buffers ever reopened. I think that thanks to our line-maps implementation, we can do the seeking quite more efficiently in terms of computation time. However, opening files is quite embedded into CPP, so that would need to be factored out so we can avoid any unnecessary CPP stuff when reopening but still do it *properly* and *efficiently*. [A basic implementation is available in GCC 4.8 -fdiagnostics-show-caret]

  5. Changes in the diagnostics machinery to extract locations from expr and print a string from a source file instead of re-constructing things.
  6. Handle locations during folding or avoid aggressive folding in the front-ends.
  7. Handle locations during optimisation or update middle-end diagnostics to not rely in perfect location information. This probably means not using %qE, not column info, and similar limitations. Some trade-off must be investigated.

B) Printing accurate column information. This requires:

C) Consistent diagnostics. This requires:

D) Printing Ranges. This requires:

E) Caret diagnostics. This requires: [FIXED in GCC 4.8 with -fdiagnostics-show-caret]

F) Precision in Wording 

void foo(int i)
{
  *i = 0;
}
  $ gcc-4.8 -fsyntax-only t.c
precisionword2.c: In function ‘foo’:
precisionword2.c:3:3: error: invalid type argument of unary ‘*’ (have ‘int’)
   *i = 0;
   ^
  $ clang -fsyntax-only t.c
precisionword2.c:3:3: error: indirection requires pointer operand ('int' invalid)
  *i = 0;
  ^~

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

int main()
{
  void *p = 0;
  p += 1;
  p++;
}

$ gcc-4.8 -Wpedantic
precisionword4.c: In function ‘main’:
precisionword4.c:4:5: warning: pointer of type ‘void *’ used in arithmetic [-Wpedantic]
   p += 1;
     ^
precisionword4.c:5:4: warning: wrong type argument to increment [-Wpedantic]
   p++;
    ^
$ clang -Wpedantic
precisionword4.c:4:5: warning: arithmetic on a pointer to void is a GNU extension [-Wpointer-arith]
  p += 1;
  ~ ^
precisionword4.c:5:4: warning: arithmetic on a pointer to void is a GNU extension [-Wpointer-arith]
  p++;
  ~^

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25801

G) Typedef Preservation and Selective Unwrapping: Clang (LLVM) expressive diagnostics. 

  $ 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 *')

  $ 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>')

H) Fix-it Hints 

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

I) Automatic Macro Expansion [FIXED in GCC 4.8 with -fdiagnostics-show-caret -ftrack-macro-expansion]

J) Spell-checker

K) Precise locations within strings (PR52952)

L) Template type diffing: http://clang.llvm.org/diagnostics.html

M) Color:

Notes:

None: Better_Diagnostics (last edited 2013-04-04 19:14:47 by ManuelLópezIbáñez)