[Bug c/90680] New: Misleading fixit warning with pointers to pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90680
Bug ID: 90680
Summary: Misleading fixit warning with pointers to pointers
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: blitzrakete at gmail dot com
Target Milestone: ---
Consider:
int main(void) {
struct { int a; } **p;
p->a; // error
}
gcc gives me:
: In function 'main':
:3:6: error: '*p' is a pointer; did you mean to use '->'?
3 | p->a;
| ^~
| ->
I realize that the error is good enough, since it does say that *p is a pointer
type, which is correct. But it should not tell me to use ->.
[Bug c++/90572] New: Wrong disambiguation in friend declaration as implicit typename context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90572
Bug ID: 90572
Summary: Wrong disambiguation in friend declaration as implicit
typename context
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blitzrakete at gmail dot com
Target Milestone: ---
template struct C {
friend C(T::fn)(); // not implicit typename context, declarator-id of friend
// declaration
};
Courtesy of rsmith. gcc fails to compile this with -std=c++2a, but accepts it
in C++17 mode.
:11:19: error: ISO C++ forbids declaration of 'C' with no type
[-fpermissive]
11 | friend C(T::fn)(); // not implicit typename context, declarator-id
of friend
| ^
:11:19: error: 'C' declared as function returning a function
gcc interprets this as a function taking a T::fn and returning a function,
while it should be a function returning C taking no parameters with the
(qualified) name T::fn.
[Bug c++/90342] New: Misleading #include system fixit when using an older C++ version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90342
Bug ID: 90342
Summary: Misleading #include system fixit when using an older
C++ version
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blitzrakete at gmail dot com
Target Milestone: ---
#include
int main() {
std::make_unique();
}
If I compile this with -std=c++11, I get:
: In function 'int main()':
:4:8: error: 'make_unique' is not a member of 'std'
4 | std::make_unique();
|^~~
:2:1: note: 'std::make_unique' is defined in header ''; did you
forget to '#include '?
1 | #include
+++ |+#include
2 |
:4:20: error: expected primary-expression before 'int'
4 | std::make_unique();
|^~~
Compiler returned: 1
That note is very misleading, since failing to include that header is not the
reason why std::make_unique doesn't exist.
[Bug c++/89642] gcc rejects valid implicit typename context in cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89642 --- Comment #2 from Nicolas Lesser --- Sorry, I forgot the most important part of the bug report: This is C++20. clang doesn't implement this feature (yet), so it would naturally reject it as is valid in pre C++20. icc has a bug since it accepts it.
[Bug c++/89642] New: gcc rejects valid implicit typename context in cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89642
Bug ID: 89642
Summary: gcc rejects valid implicit typename context in cast
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blitzrakete at gmail dot com
Target Milestone: ---
template
void f(T t) {
static_cast(t); // gcc rejects, but this is well-formed
}
gcc rejects the above with:
: In function 'void f(T)':
:3:18: error: expected '>' before '(' token
3 | static_cast(t);
| ^
But the code is well-formed, since the smallest enclosing type-id of
`int(T::type)` is the type-id of the static_cast, which is a valid type-id-only
context as per [temp.res]p5.
[Bug c++/89636] New: Duplicate diagnostic when resolving ambiguity between variable and function template using implicit typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89636
Bug ID: 89636
Summary: Duplicate diagnostic when resolving ambiguity between
variable and function template using implicit typename
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blitzrakete at gmail dot com
Target Milestone: ---
namespace N {
inline namespace A { template int f(typename T::type); }
inline namespace B { template int f(T::type); }
}
template
int N::f(T::type); // ill-formed
For the above code, compiled with -std=c++2a, gcc generates:
:7:5: error: reference to 'f' is ambiguous
7 | int N::f(T::type); // ill-formed
| ^
:2:50: note: candidates are: 'template int N::A::f(typename
T::type)'
2 | inline namespace A { template int f(typename T::type); }
| ^
:3:50: note: 'template int N::B::f'
3 | inline namespace B { template int f(T::type); }
| ^
:7:17: error: reference to 'N::f' is ambiguous
7 | int N::f(T::type); // ill-formed
| ^
:2:50: note: candidates are: 'template int N::A::f(typename
T::type)'
2 | inline namespace A { template int f(typename T::type); }
| ^
:3:50: note: 'template int N::B::f'
3 | inline namespace B { template int f(T::type); }
| ^
Note the duplicate diagnostic. First it errors on just `f` being ambiguous,
then it does the same thing with `N::f`, but they're the same. I'd expect only
the second one to be emitted.
[Bug c++/88358] variable template definition taken as function template declaration with implicit typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88358
--- Comment #4 from Nicolas Lesser ---
Almost the same fix has to apply when the declarator is unqualified: Always
treat T::something as a value, never as a type. This is not part of the allowed
contexts in P0634. I don't know which core discussion you're referring to, but
this is still a well-formed program:
template
int pi(T::your_pi);
struct Foo { static constexpr int your_pi = 10; };
int main() {
return pi; // gcc rejects
}
[Bug c++/88358] New: variable template definition taken as function template declaration with implicit typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88358 Bug ID: 88358 Summary: variable template definition taken as function template declaration with implicit typename Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: blitzrakete at gmail dot com Target Milestone: --- Consider the following (compiled with `-std=c++2a`): template void f(T::type); // ill-formed, gcc accepts gcc seems to think that this is a function template declaration. In fact, it is not, it's an ill-formed variable template. It's also a regression I think in a way template int pi(T::your_pi); // variable template, but gcc trunk thinks this is a function template
[Bug c++/88313] New: generic lambda in default template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88313 Bug ID: 88313 Summary: generic lambda in default template argument Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: blitzrakete at gmail dot com Target Milestone: --- gcc (with no flags) rejects the following code: // 'auto' parameter not permitted in this context template void f(); This is bogus because anywhere where a non-generic lambda is allowed, a generic one is allowed too. Replacing 'auto' with 'int' makes gcc accept the code.
[Bug c++/87971] gcc allows nested namespace definition of inline namespaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87971 Nicolas Lesser changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Nicolas Lesser --- Ha, seems like you're right. It's just the other way that is ill-formed.
[Bug c++/87971] New: gcc allows nested namespace definition of inline namespaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87971
Bug ID: 87971
Summary: gcc allows nested namespace definition of inline
namespaces
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blitzrakete at gmail dot com
Target Milestone: ---
gcc allows the following code with -std=c++17 without any warnings or errors
even with -Wall -Wextra -pedantic -pedantic-errors.
namespace one {
inline namespace two {}
}
namespace one::two {} // ill-formed
two is an inline namespace, so it should be specified as such.
[Bug c++/87724] New: gcc allows narrowing conversions in converted constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87724
Bug ID: 87724
Summary: gcc allows narrowing conversions in converted constant
expressions
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blitzrakete at gmail dot com
Target Milestone: ---
Compiled with -std=c++17 (https://godbolt.org/z/fO32Pd)
int main() {
static_assert(2); // ill-formed, gcc accepts
if constexpr (2); // ill-formed, gcc accepts
}
2 doesn't fit in a bool, and as such it is a narrowing conversion and fails to
be a "contextually converted constant expression of type bool" as per
[expr.const]p5.
[Bug c++/87174] New: virt-specifier not recognized on function declared like a variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87174
Bug ID: 87174
Summary: virt-specifier not recognized on function declared
like a variable
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blitzrakete at gmail dot com
Target Milestone: ---
Gcc (no flags) doesn't compile the following code:
using F = void();
struct X {
virtual F f;
};
struct Y : X {
F f override;
};
Clang can compile this code just fine. The (trimmed) error message is:
:8:5: error: expected ';' at end of member declaration
:8:7: error: 'override' does not name a type
[Bug c++/87035] Can't shadow global const int with unnamed enum in class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87035 --- Comment #4 from Nicolas Lesser --- Nice, thank you!
[Bug c++/87035] Can't shadow global const int with unnamed enum in class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87035 --- Comment #2 from Nicolas Lesser --- Huh, interesting. TIL. Where's that rule in the standard? Because I can't find it in [class.mem]. Is it somewhere else or did I just overlook it?
[Bug c++/87035] New: Can't shadow global const int with unnamed enum in class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87035
Bug ID: 87035
Summary: Can't shadow global const int with unnamed enum in
class
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blitzrakete at gmail dot com
Target Milestone: ---
const int N = 5;
struct X {
int Array[N]; // int[5]
enum { N }; // fails, redeclaration
};
This is well-formed, as the enum value N is in another scope and so shadows
::N. Removing the array declaration makes the code also compile.
[Bug c++/86942] New: A trailing-return-type is allowed when the return type is not 'auto' for using declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86942
Bug ID: 86942
Summary: A trailing-return-type is allowed when the return type
is not 'auto' for using declarations
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blitzrakete at gmail dot com
Target Milestone: ---
void test() -> void; // fail => ok
using function = void() -> int; // allowed?!?
int f();
int main() {
function *Boo = f; // not ok; trailing return type is ignored
}
The above code fails to compile on the latest gcc trunk. It is invalid as a
trailing-return-type can only appear if the return type of the function is
'auto'.
No arguments to g++ necessary. Online demo: https://godbolt.org/g/XtSw6T
[Bug c++/86870] Declaration disambiguation is too greedy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86870 --- Comment #1 from Nicolas Lesser --- Oops, I missed to define a default constructor for `X`. This however, does not change the bug report and gcc still incorrectly parses the second statement as a declaration.
[Bug c++/86870] New: Declaration disambiguation is too greedy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86870
Bug ID: 86870
Summary: Declaration disambiguation is too greedy
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blitzrakete at gmail dot com
Target Milestone: ---
struct X {
void operator=(int);
} x;
int main() {
1 + 1, X(x) = 4; // ok
X(x) = 4, 1 + 1; // gcc fails
}
gcc cannot compile the second statement, because it thinks it is a declaration,
even though it is not. EDG compiles this just fine (clang and MSVC do not).
[Bug c++/86703] template auto fails deduction, where template int succeeds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86703
Nicolas Lesser changed:
What|Removed |Added
CC||blitzrakete at gmail dot com
--- Comment #1 from Nicolas Lesser ---
Here's another reduce example.:
struct X {};
template using Auto = X;
template constexpr Auto<(T(), 0)> match() { return {}; }
X x = match();
Without ", 0" the example compiles. Error message:
main.cpp:5:18: error: no matching function for call to ‘match()’
X x = match();
^
main.cpp:4:48: note: candidate: ‘template constexpr Auto<(T(), 0)>
match()’
template constexpr Auto<(T(), 0)> match() { return {}; }
^
main.cpp:4:48: note: template argument deduction/substitution failed:
main.cpp: In substitution of ‘template > using Auto = X [with
auto = ((void)0, 0)]’:
main.cpp:4:48: required by substitution of ‘template constexpr
Auto<(T(), 0)> match() [with T = int]’
main.cpp:5:18: required from here
main.cpp:4:48: error: integral expression ‘((void)0, 0)’ is not constant
main.cpp:4:48: error: trying to instantiate ‘template >
using Auto = X’
[Bug c++/86369] constexpr const char* comparison fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86369 Nicolas Lesser changed: What|Removed |Added CC||blitzrakete at gmail dot com --- Comment #1 from Nicolas Lesser --- For clarity, b1 shouldn't compile. [lex.string]p16 says: "whether successive evaluations of a string-literal yield the same or a different object is unspecified." [expr.const]p2 says: "An expression e is a core constant expression unless the evaluation of e, [...], would evaluate one of the following expressions: [...]; a relational or equality operator where the result is unspecified;"
[Bug c++/86049] New: Array bindings are not const when initializer is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86049
Bug ID: 86049
Summary: Array bindings are not const when initializer is
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blitzrakete at gmail dot com
Target Milestone: ---
Compiles with clang, doesn't under gcc 8.1.0:
template struct is_same {
static constexpr bool value = false;
};
template struct is_same {
static constexpr bool value = true;
};
int main() {
const int Array[] = {1};
auto[One] = Array;
static_assert(is_same::value); // fail
}
[dcl.struct.bind]p1 is pretty clear here that the type of the underlying
structured binding element is const int[1], and so per [dcl.struct.bind]p2 the
element type is const int and thus so is also One's type.
