TODO.txt

//===---------------------------------------------------------------------===//
// Minor random things that can be improved
//===---------------------------------------------------------------------===//
   

Warn about "X && 0x1000" saying that the user may mean "X & 0x1000".
We should do this for any immediate except zero, so long as it doesn't come 
from a macro expansion.  Likewise for ||.

//===---------------------------------------------------------------------===//

Lexer-related diagnostics should point to the problematic character, not the
start of the token.  For example:

int y = 0000\
00080;

diag.c:4:9: error: invalid digit '8' in octal constant
int y = 0000\
        ^

should be:

diag.c:4:9: error: invalid digit '8' in octal constant
00080;
   ^

This specific diagnostic is implemented, but others should be updated.

//===---------------------------------------------------------------------===//

C++ (checker): For iterators, warn of the use of "iterator++" instead
  of "++iterator" when when the value returned by operator++(int) is
  ignored.

//===---------------------------------------------------------------------===//

We want to keep more source range information in Declarator to help
produce better diagnostics. Declarator::getSourceRange() should be
implemented to give a range for the whole declarator with all of its
specifiers, and DeclaratorChunk::ParamInfo should also have a source
range covering the whole parameter, so that an error message like this:

overloaded-operator-decl.cpp:37:23: error: parameter of overloaded post-increment operator must have type 'int' (not 'float')
X operator++(X&, const float& f); 
                              ^
can be turned into something like this:

overloaded-operator-decl.cpp:37:23: error: parameter of overloaded post-increment operator must have type 'int' (not 'float')
X operator++(X&, const float& f); 
  ^              ~~~~~~~~~~~~~~

//===---------------------------------------------------------------------===//

For terminal output, we should consider limiting the amount of
diagnostic text we print once the first error has been
encountered. For example, once we have produced an error diagnostic,
we should only continue producing diagnostics until we have produced a
page full of results (say, 50 lines of text). Beyond that, (1) the
remaining errors are likely to be less interesting, and (2) the poor
user has to scroll his terminal to find out where things went wrong.

//===---------------------------------------------------------------------===//
More ideas for code modification hints:
  - If no member of a given name is found in a class/struct, search through the names of entities that do exist in the class and suggest the closest candidate. e.g., if I write "DS.setTypeSpecType", it would suggest "DS.SetTypeSpecType" (edit distance = 1).
  - If a class member is defined out-of-line but isn't in the class declaration (and there are no close matches!), provide the option to add an in-class declaration.
  - Fix-it hints for the inclusion of headers when needed for particular features (e.g., <typeinfo> for typeid)
  - Change "foo.bar" to "foo->bar" when "foo" is a pointer.