[Bug c++/53415] problematic error message for ambiguity

2019-03-07 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53415

--- Comment #3 from Jonathan Wakely  ---
P.S. also -pedantic-errors makes it an error, not just a warning

[Bug c++/53415] problematic error message for ambiguity

2019-03-07 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53415

--- Comment #2 from Jonathan Wakely  ---
(In reply to Nathan Ridge from comment #0)
> 1. Template argument deduction/substitution is failing because of a
> *warning*? The following reduced example:
> 
> struct string
> {
> string(char*);
> };
> 
> template 
> void operator+(const string&, const T&);
> 
> struct T
> {
> enum {value = 0};
> };
> 
> int main()
> {
> return 0 + T::value; 
> }
> 
> gives a similar warning but no errors. It is inconsistent for an ambiguity
> to cause just a warning in one case, and failure of template argument
> deduction/substitution in another.

That's by design. G++ extensions that change the meaning of ill-formed code are
disabled in SFINAE contexts. This is similar to the -Wnarrowing option, for
which the manual says:

"Note that this does not affect the meaning of well-formed code; narrowing
conversions are still considered ill-formed in SFINAE contexts."

This ensures that static properties of the code (e.g. detectable using decltype
or other compile-time metaprogramming) are consistent with other compilers that
don't implement the same non-standard extension.

> 2. There is no caret diagnostic associated with the "ISO C++ says that these
> are ambiguous" warning, so it's difficult to tell what "these" are. (We can
> infer from the candidates being operator+, but there could have been many
> uses of operator+ in that expression, and only one of them ambiguous, so it
> would be nice to have a caret pointing to that one).

I can't reproduce this part of the report, I see a location for the ambiguity,
with all versions I tested from 4.8.0 onwards:

a.cc:19:5: warning: ISO C++ says that these are ambiguous, even though the
worst conversion for the first is better than the worst conversion for the
second: [enabled by default]
 S<0 + T::value> foo(X);
 ^

Since GCC 6 it's a range not a single location:

a.cc:19:5: warning: ISO C++ says that these are ambiguous, even though the
worst conversion for the first is better than the worst conversion for the
second:
 S<0 + T::value> foo(X);
   ~~^~

And with current trunk the range is correct :-)

a.cc:19:5: warning: ISO C++ says that these are ambiguous, even though the
worst conversion for the first is better than the worst conversion for the
second:
   19 | S<0 + T::value> foo(X);
  |   ~~^

[Bug c++/53415] problematic error message for ambiguity

2012-06-08 Thread manu at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53415

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-06-08
 CC||manu at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  2012-06-08 
23:47:03 UTC ---
I think there are quite a few bugs here. Starting with the
template-parameter-1-1 output.

Clang is not very helpful in this case:

/tmp/webcompile/_14729_0.cc:23:5: error: no matching function for call to 'foo'
foo(1);
^~~
/tmp/webcompile/_14729_0.cc:19:20: note: candidate template ignored:
substitution failure [with X = int]
S<0 + T::value> foo(X);
   ^
1 error generated.