[Bug c++/17314] Error message wrongly shows declared rather than inherited access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17314
Igel changed:
What|Removed |Added
CC||ich.freak at gmx dot net
--- Comment #21 from Igel ---
Seconded! This bug still exists in 9.2.0. Here's another example:
class Base { protected: int i; };
class Derived: public Base{ using Base::i; };
class Derived2: public Derived { using Derived::i; };
int main(){}
> g++ test.cpp -o test
test.cpp:3:7: error: 'int Base::i' is protected within this context
3 | class Derived2: public Derived { using Derived::i; };
| ^~~~
test.cpp:1:30: note: declared protected here
1 | class Base { protected: int i; };
| ^
no mention of line 2 where the actual problem is (namely that i is declared
private (not protected)).
cheers
[Bug c++/105307] New: -fmax-errors truncated for concept diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105307
Bug ID: 105307
Summary: -fmax-errors truncated for concept diagnostics
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ich.freak at gmx dot net
Target Milestone: ---
In #92440 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92440) it was remarked
that -fmax-errors=1 truncates the first error "in the middle of the sentence"
and a patch was supplied. However, the problem still persists for concepts:
template concept HasX = requires { T::x; };
template struct S {};
struct NoX {};
S s;
compiled with
> g++ -std=c++20 -fconcepts-diagnostics-depth=3 test.cpp -o test
yields:
>test.cpp:4:6: error: template constraint failure for 'template
>>requires HasX struct S'
>4 | S s;
> | ^
>test.cpp:4:6: note: constraints not satisfied
>test.cpp: In substitution of 'template requires HasX struct S
>>[with T = NoX]':
>test.cpp:4:6: required from here
>test.cpp:1:26: required for the satisfaction of 'HasX' [with T = NoX]
>test.cpp:1:33: in requirements [with T = NoX]
>test.cpp:1:47: note: the required expression 'T::x' is invalid, because
>1 | templateconcept HasX = requires { T::x; };
> | ^
>test.cpp:1:47: error: 'x' is not a member of 'NoX'
And, if we add -fmax-errors=1, we get:
>test.cpp:4:6: error: template constraint failure for 'template
>>requires HasX struct S'
>4 | S s;
> | ^
>test.cpp:4:6: note: constraints not satisfied
>test.cpp: In substitution of 'template requires HasX struct S
>>[with T = NoX]':
>test.cpp:4:6: required from here
>test.cpp:1:26: required for the satisfaction of 'HasX' [with T = NoX]
>test.cpp:1:33: in requirements [with T = NoX]
>test.cpp:1:47: note: the required expression 'T::x' is invalid, because
>1 | templateconcept HasX = requires { T::x; };
> | ^
>compilation terminated due to -fmax-errors=1.
However, the "explanatory errors" that are getting truncated here still
logically belong to the same error and should, therefore, not be truncated.
[Bug c++/92440] Error output for first error truncated with -fmax-errors=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92440 Igel changed: What|Removed |Added CC||ich.freak at gmx dot net --- Comment #5 from Igel --- this still persists for concept diagnostics: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105307
[Bug c++/105307] -fmax-errors truncated for concept diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105307 --- Comment #3 from Igel --- well, quite surely, > error: 'x' is not a member of 'NoX' is not the only instance of this problem. It seems to me that gcc is not differentiating "normal errors" from "explanatory errors", and I guess introducing this difference would actually be somewhat of a larger refactorization. I'm just speculating tho here...
[Bug c++/103239] New: confusing template argument deduction error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103239
Bug ID: 103239
Summary: confusing template argument deduction error message
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ich.freak at gmx dot net
Target Milestone: ---
When trying to resolve a function call, GCC iterates through the candidates,
checking if it can deduce/substitute template parameters. When failing to
deduce/substitute, it outputs nicely why it failed to do so. However, when 2
candidates fail for the same reason, it appears that this reason is only
printed for the first candidate, not for the second one, leaving the user with
a confusing message such as
[...]
note: template argument deduction/substitution failed:
:8:5: note: candidate: [...]
that is, no reason is printed after the colon and, instead, the next candidate
is listed. This seems surprising and unintended. It would be nice to tell the
user why deduction/substitution failed for his/her favorite candidate.
I drafted a small example here: https://godbolt.org/z/PjeGa3YPe
The code is:
#include
template struct X {
using T = int;
template using Z = Y::T;
X() = default;
template> X(Y&& y, int, Q&& q = Q()) {}
template>
X(Y&& y, int, Q&& q = Q(), int ignore = 10) {}
};
int main () {
const X<0> x = X<0>();
X<0> y(x, 0);
}
[Bug c++/103540] New: diagnosting concept depends on itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103540 Bug ID: 103540 Summary: diagnosting concept depends on itself Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ich.freak at gmx dot net Target Milestone: --- When a concept X is checked for a template parameter T, this parameter is fully instanciated. (while this may not be necessary to check the concept, this seems to be dictated by the standard if I understood correctly) If the instanciation of T depends on the concept X, then gcc refuses to compile the code saying something like "satisfaction of atomic constraint X depends on itself". If T is large, however, it may be very difficult to determine where exactly T depends on X and gcc currently does not help at all to find the problem. It would be nice if gcc could tell the reader something like "X depends on itself because the type T::something declared in line Z depends on X" I prepared a small example here <https://godbolt.org/z/q9KczYb16>. Note that diagnostics end with :5:14: note: the required type 'typename N::something' is invalid, because 5 | typename N::something; | ~^ Compiler returned: 1 leaving the reader to wonder "because of what?"
[Bug c++/103540] diagnosting concept depends on itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103540
--- Comment #2 from Igel ---
Ah thanks for copying the relevant code here. The error that you're referring
to is:
: In instantiation of 'struct X<0>':
:5:14: required by substitution of 'template requires
StrictNodeType using Int = int [with N = X<0>]'
:15:27: required from here
:12:11: error: template constraint failure for 'template
requires StrictNodeType using Int = int'
12 | using something = Int;
| ^
:12:11: note: constraints not satisfied
I guess technically, you're right that it points to the correct spot and it is
the programmers duty to translate this into
"the concept StrictNodeType> depends on itself because the type
X<0>::something (also known as Int>) declared in line 12 depends on the
concept StrictNodeType>".
However, this information can be buried arbitrarily deep in the error messages.
Consider, for example, the following adaptation:
#include
template
concept StrictNodeType = requires {
typename N::something;
};
template using Int = int;
template class P, class Q>
using chooser = P;
template
struct X { using something = chooser; };
using ThisBreaks = Int>;
The only hint towards the real problem (gcc cannot tell if X<0> has a type
called 'something' or not) is now this:
:14:18: required from 'struct X<0>'
I guess all I'm saying is that extracting the site of the problematic code is
currently very hard for "depends on itself"-errors.
