[Bug c++/56084] poor error recovery for missing ";"

2021-06-01 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56084

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|9.5 |---

[Bug c++/56084] poor error recovery for missing ";"

2021-06-01 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56084

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|9.4 |9.5

--- Comment #13 from Richard Biener  ---
GCC 9.4 is being released, retargeting bugs to GCC 9.5.

[Bug c++/56084] poor error recovery for missing ";"

2020-03-12 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56084

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|9.3 |9.4

--- Comment #12 from Jakub Jelinek  ---
GCC 9.3.0 has been released, adjusting target milestone.

[Bug c++/56084] poor error recovery for missing ";"

2019-08-12 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56084

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|9.2 |9.3

--- Comment #11 from Jakub Jelinek  ---
GCC 9.2 has been released.

[Bug c++/56084] poor error recovery for missing ";"

2019-05-03 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56084

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|9.0 |9.2

--- Comment #10 from Jakub Jelinek  ---
GCC 9.1 has been released.

[Bug c++/56084] poor error recovery for missing ";"

2018-06-16 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56084

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #9 from Eric Gallager  ---
ASSIGNED because it already has an assignee.

[Bug c++/56084] poor error recovery for missing ";"

2018-03-16 Thread dmalcolm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56084

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
   Target Milestone|--- |9.0

[Bug c++/56084] poor error recovery for missing ;

2013-01-23 Thread manu at gcc dot gnu.org

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

Manuel López-Ibáñez manu at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-01-23 
15:44:21 UTC ---
Originally from:
http://stackoverflow.com/questions/8205858/clang-vs-gcc-for-linux-development-compare-and-contrast


[Bug c++/56084] poor error recovery for missing ;

2013-01-23 Thread redi at gcc dot gnu.org


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



Jonathan Wakely redi at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-01-23

 Ever Confirmed|0   |1



--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-23 
16:25:18 UTC ---

This reduces to:



struct ostream { };



struct A {

int i;

}



ostream operator(ostream o, const A) { return o; }



int main()

{

A a;

ostream o;

o  a;

}



which still gives a poor error that doesn't identify the problem, but it

doesn't give pages of errors because there is only one operator in scope



x.cc:7:8: error: expected initializer before '' token

 ostream operator(ostream o, const A) { return o; }

^

x.cc: In function 'int main()':

x.cc:13:7: error: no match for 'operator' (operand types are 'ostream' and

'A')

 o  a;

   ^



(Separately, I'm investigating whether there's some way to reduce the output

when an invalid ostream operation is done, because the sheer number of

overloads of operator causes pages of output due to G++'s verbose, and

usually very useful, output describing argument deduction errors.)


[Bug c++/56084] poor error recovery for missing ;

2013-01-23 Thread manu at gcc dot gnu.org

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

--- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-01-23 
17:02:02 UTC ---
 (Separately, I'm investigating whether there's some way to reduce the output
 when an invalid ostream operation is done, because the sheer number of
 overloads of operator causes pages of output due to G++'s verbose, and
 usually very useful, output describing argument deduction errors.)

One clear way is to avoid the repetition of:

In file included from
/home/manuel/test1/195333M/install/include/c++/4.8.0/iostream:40:0,
 from test.cc:2:

Another is to add a foverload-candidates-limit option like
ftemplate-backtrace-limit, so if there are more than the limit (let's say 5),
the output is elided in a similar fashion.

Another suggestion is to don't show the full function declaration like in:

In file included from
/home/manuel/test1/195333M/install/include/c++/4.8.0/iostream:40:0,
 from test.cc:2:
/home/manuel/test1/195333M/install/include/c++/4.8.0/ostream:532:5: note:
templateclass _Traits std::basic_ostreamchar, _Traits
std::operator(std::basic_ostreamchar, _Traits, const char*)
 operator(basic_ostreamchar, _Traits __out, const char* __s)
 ^
/home/manuel/test1/195333M/install/include/c++/4.8.0/ostream:532:5: note:  
template argument deduction/substitution failed:
test.cc:16:16: note:   cannot convert ‘me’ (type ‘Student’) to type ‘const
char*’
   std::cout  me  \n;
^

where clang says in 1 line:

/usr/lib/gcc/x86_64-linux-gnu/4.4/../../../../include/c++/4.4/bits/ostream.tcc:320:5:
note: candidate function [with _CharT = char, _Traits = std::char_traitschar]
not viable: no known conversion from 'Student' to 'const char *' for 2nd
argument
operator(basic_ostream_CharT, _Traits __out, const char* __s)


[Bug c++/56084] poor error recovery for missing ;

2013-01-23 Thread manu at gcc dot gnu.org

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

--- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-01-23 
17:05:14 UTC ---
BTW, what is the difference between deduction and substitution?


[Bug c++/56084] poor error recovery for missing ;

2013-01-23 Thread manu at gcc dot gnu.org

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

--- Comment #5 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-01-23 
17:10:58 UTC ---
Of course, the color output makes much easier to spot the note:. And the use
of a common prefix note: candidate function... or note: candidate
template... also makes easier to spot the start of each individual
explanation.


[Bug c++/56084] poor error recovery for missing ;

2013-01-23 Thread glisse at gcc dot gnu.org


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



--- Comment #6 from Marc Glisse glisse at gcc dot gnu.org 2013-01-23 17:17:53 
UTC ---

(In reply to comment #5)

 Of course, the color output makes much easier to spot the note:.



Er, not here, bold black (the color they chose for note:) on a black

background is pretty hard to read...

(otherwise I agree that colors help)


[Bug c++/56084] poor error recovery for missing ;

2013-01-23 Thread manu at gcc dot gnu.org

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

--- Comment #7 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-01-23 
17:31:21 UTC ---
Strange. In the GCC farm and without any customization, clang uses gray for the
note. I have seen presentations where it also uses this color scheme. I don't
know if they have some brackground-color detection, and it fails in your case.


[Bug c++/56084] poor error recovery for missing ;

2013-01-23 Thread redi at gcc dot gnu.org


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



--- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-23 
17:44:24 UTC ---

(In reply to comment #4)

 BTW, what is the difference between deduction and substitution?



Some template arguments are deduced from the function arguments, and those

arguments are then substituted into the rest of the function template signature

to form a function signature.



e.g.



templatetypename T, typename U=T

void func(T, typename T::iterator)

{ }



If you call 'func(v, v.begin())' then T will be deduced from the type of 'v', U

will be deduced as the same type, then that type will be substituted into the

type T::iterator. If 'v' has no nested 'iterator' type then substitution fails

and so deduction fails, and the template cannot be called.