Reputation: 55
I am not actually sure how to explain this but basically when I execute this (clang/gcc):
gcc -std=c++11 -Wall -fsyntax-only test.cpp
test.cpp:
struct tmp1
{
tmp1() { _1 = 12; }
int _1;
int _2;
bool y;
};
class tmp2
{
private:
tmp1 in;
public:
tmp2(const tmp1& val) : in{val}
{
in._1 = ""
}
};
I am getting two "different" diagnostics:
GCC:
/Desktop/test.cpp: In constructor ‘tmp2::tmp2(const tmp1&)’:
./Desktop/test.cpp:18:15: error: invalid conversion from ‘const char*’ to ‘int’ [-fpermissive]
in._1 = ""
^
./Desktop/test.cpp:19:5: error: expected ‘;’ before ‘}’ token
}
^
Clang:
./Desktop/test.cpp:18:15: error: assigning to 'int' from incompatible type
'const char [1]'
in._1 = ""
^ ~~
So my question is how do I get the additional diagnostic from GCC which says that there is an expcted token after '}' in clang?
Upvotes: 0
Views: 1062
Reputation: 129474
More explicit in what way? One of the problems in compilers, when you find something "that doesn't belong there", is to decide where you "continue from". It's a bit like if I tell you that "Go onto Road A, then turn left by the big oak tree onto Road B, then take the second left, and go 50 yards and you're at my house". But unknown to me, the big oaktree has been cut down because it was a danger to passing traffic, so you keep going for about a mile and a half until you find a different oak tree. Now, you won't find my house, right?
So, where do the compiler developer pick as the "next place to go on", when s/he finds the "wrong type" (a string instead of a number)? Were do we continue going? What is our "landmark" that we use to get back on track again? This is actually quite hard (the compiler I've written often fails horribly when hitting "unexpected stuff").
Or do you mean that the compiler should say "You are trying to assign a string to an int
"? Again, the real problem here is that there is a gazillion ways that you can combine type X with type Y - string to integer, integer to string, float to string, string to float, struct to class, class to struct, class to integer, integer to class, class to class, pointer to integer, integer to pointer. Some of these are indeed distinctive errors. Others are not.
I'll be back with a refernce to where in Clang this error is printed, and maybe we can study it to figure out if it can be improved upon.
Upvotes: 1