Differences between revisions 35 and 36
Revision 35 as of 2013-04-04 19:05:51
Size: 11140
Comment: remove fixed examples, add new examples of precision in wording
Revision 36 as of 2013-04-04 19:14:47
Size: 11199
Comment: one more example
Deletions are marked like this. Additions are marked like this.
Line 123: Line 123:
[[http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25801]]

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:

  • #) Preprocessed/original locations in a single location_t. Similar as (A.0) above. [FIXED in GCC 4.7 with -ftrack-macro-expansion]

  • #) Changes in the parser to pass down the correct locations to diagnostics machinery. Similar to (A.2) above.
  • B.1) Changes in the testsuite to enable testing column numbers. [FIXED?]

C) Consistent diagnostics. This requires:

  • C.1) Make CPP use the diagnostics machinery. This will fix part of PR7263 and other similar bugs where there is a mismatch between the diagnostics machinery and CPP's own diagnostics machinery. [FIXED in GCC 4.5, PR7263 fixed in GCC 4.8]

  • #) Preprocessed/original locations in a single location_t. This will avoid different behaviour when a token comes from a macro expansion. Similar as (A.0) above. [FIXED in GCC 4.7 with -ftrack-macro-expansion]

D) Printing Ranges. This requires:

  • #) Printing accurate column information. Similar to (B) above.
  • #) A location(s) -> source strings interface and machinery. Similar to (A.3) above.

  • #) Track beg/end locations. Similar to (A.1.b) above.
  • #) Changes in the parser to pass down ranges. Similar to (A.2) above.
  • D.1) Changes in the testsuite to enable testing ranges.
  • D.2) Changes in the diagnostics machinery to handle ranges.

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

  • #) Printing accurate column information. Similar to (B) above.
  • #) A location(s) -> source strings interface and machinery. Similar to (A.3) above.

  • E.1) Changes in the diagnostics machinery to print the source line and a 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)