Possible messaging changes

[Arthur Schwarz <aschwarz1309 at verizon dot net>]

In  light of the foolhardy commitment I made, here are some reprehensible diagnostic messages and the superb recanting of the obvious. As always, the messaging and comments are gratuitously provided and I hope accepted in the same manner.

Two notes (made before):
1: Some messages are needlessly garrulous. You have noted this previously.
2: The length of some diagnostic messages extend beyond reason. You have
   noted this previously.
3: In a general environment with many classes, structures, typedef's, etc.
   the clear association of a diagnostic message with the offending object,
   type, etc. ads clarity. The messages included below have no clear
   association (although we might argue that garrulity adds clarity).
4: Code is not self-documenting, sic COBOL, and diagnostic messages aren't
   either. A document with messaging guidelines, message descriptions, or
   anything else might be useful. Sigh, I can probably help with this.

As a suggestion, since all headers (and included symbols) are known prior to compilation it might be possible to put all the 'names' into a symbol table for use during error generation. This allows gcc to (perhaps) publish candidate solutions when type errors are detected (see m3). 

As (yet another) suggestion, since user headers can be processed independently of code (without considering edge conditions) ya' might as well augment the first suggestion with user symbols.

And yet again, while processing a given code file, symbols contained in the code file can be used to (yet again) augment the symbol table for use in diagnostic generation.

And NOW for the failures!


/*
 * m1.cpp
*/

# include <fstream>
# include <istream>

using namespace std;

ifstream  x;
ifstream& y = x;

int main(int argc, char** argv) {
  y = x;
  return 0;
}

g++.3.4.4 output
m1.cpp: In member function `std::basic_ios<char, std::char_traits<char> >& std::basic_ios<char, std::char_traits<char> >::operator=(const std::basic_ios<char, s
td::char_traits<char> >&)':
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/ios_base.h:784: error: `std::ios_base& std::ios_base::operator=(const std::ios_base&)' is private
m1.cpp:10: error: within this context
m1.cpp: In member function `std::basic_filebuf<char, std::char_traits<char> >& std::basic_filebuf<char, std::char_traits<char> >::operator=(const std::basic_fil
ebuf<char, std::char_traits<char> >&)':
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/streambuf:776: error: `std::basic_streambuf<_CharT, _Traits>& std::basic_streambuf<_CharT, _Traits>::operator=(con
st std::basic_streambuf<_CharT, _Traits>&) [with _CharT = char, _Traits = std::char_traits<char>]' is private
m1.cpp:10: error: within this context

Almost indecipherable. The error is that operator=() is private.
"error: assignment illegal, operator '=' private in ifstream"

/*
 * m2.cpp
*/


using namespace std;

ifstream  x;
ifstream  y();

int main(int argc, char** argv) {
  return 0;
}

g++.3.4.4 output
m2.cpp:4: error: `ifstream' does not name a type
m2.cpp:5: error: `ifstream' does not name a type

Succint and clear message, however it might be clearer 
to say that "'ifstream' not found" since the message
says that 'ifstream' may be something other than a
type.

"error: ifstream not found"
"note:  candidates are in #include <fstream>"

/*
 * m3.cpp
*/

# include <istream>
# include <istream>

using namespace std;

ifstream  x;
ifstream  y();

int main(int argc, char** argv) {
  return 0;
}

g++3.4.4 messaging
m3.cpp:6: error: aggregate `std::ifstream x' has incomplete type and cannot be defined
m3.cpp:6: error: storage size of `x' isn't known

Messaging not clear. The naive issue is the 'ifstream' not found. 'std::ifstream' not
found. 'std::ifstream x' is confusing. 

If 'std::ifstream' not found, why is 'std::ifstream y();' legal?

"error: ifstream incomplete in 'istream'.