[Bug c++/97340] New: Spurious rejection of member variable template of reference type

[herring at lanl dot gov via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97340

Bug ID: 97340
   Summary: Spurious rejection of member variable template of
reference type
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: herring at lanl dot gov
  Target Milestone: ---

In many recent versions of GCC, the following valid code

  struct A {
template
static constexpr const int &x=0;
  };
  template
  struct B {
static constexpr int y=A::template x;
  };
  template struct B<>;

produces

error: ''indirect_ref' not supported by dump_decl' is not a
template [-fpermissive]
7 |   static constexpr int y=A::template x;
  |  ^~

The 'template' after '::' here is unnecessary; removing it avoids the error,
but the error also appears if A is a class template (so that it's necessary to
write "A::template x").  Making A::x not be a reference also avoids the
error, as does referring to it from a non-templated context.

[Bug c++/104577] needs copy constructor for class non-type template parameter

[herring at lanl dot gov via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104577

S. Davis Herring  changed:

   What|Removed |Added

 CC||herring at lanl dot gov

--- Comment #4 from S. Davis Herring  ---
The understood direction for CWG2459 makes it clear that class-type template
parameters must indeed be copied; in fact, they have to be copied twice in some
cases to guarantee that they have the correct value when user-provided
constructors are involved.

[Bug c++/108759] New: "mandatory copy elision" not implemented during constant evaluation redux

[herring at lanl dot gov via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108759

Bug ID: 108759
   Summary: "mandatory copy elision" not implemented during
constant evaluation redux
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: herring at lanl dot gov
  Target Milestone: ---

Extending the test case in (the invalid) #94537 to have a user-provided
destructor does not cause the "mandatory copy elision" to take place even
though the implementation is no longer permitted to introduce a temporary:

  struct A;
  extern const A a;
  struct A {
bool special=this==&a;
constexpr ~A() {}
  };
  constexpr A get() {return {};}  // or "return A();"
  constexpr A a=get();
  static_assert(a.special);

[Bug c++/89780] -Wpessimizing-move is too agressive with templates and recommends pessimization

[herring at lanl dot gov via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89780

--- Comment #3 from S. Davis Herring  ---
Does this need to be language-version-dependent, given
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1825r0.html (in
C++20) and
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2266r3.html (in
C++23)?

[Bug c++/89780] -Wpessimizing-move is too agressive with templates and recommends pessimization

[herring at lanl dot gov via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89780

--- Comment #5 from S. Davis Herring  ---
Perhaps I'm misunderstanding something, but your example (as well as compiling
the original example with -std=c++20, which produces the same warning but now
calls Dest(Dest&&) in the noMove case) means that the warning is
correct in C++20 mode (but not in C++17).  If that's the case, why suppress the
warning in formerly dependent contexts regardless of language version?

[Bug c++/89780] -Wpessimizing-move is too agressive with templates and recommends pessimization

[herring at lanl dot gov via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89780

--- Comment #7 from S. Davis Herring  ---
> In the withMove case, in C++20, we issue:
> warning: moving a local object in a return statement prevents copy elision
> for
> template Dest withMove();
> and:
> warning: redundant move in return statement
> for
> template Dest withMove();

Each of these in isolation is of course correct (which was of course never in
question).

> With my patch, we won't issue any warnings, because I'm not sure if we
> can say that in *any* instantiation of withMove the std::move is
> wrong.  Am I mistaken?

P1825R0 makes it much less likely that removing the std::move is ever a
problem.  There are cases that still need it, like

  struct A {
operator Dest() &&;
  };
  template Dest withMove();

That said, P2266R3 makes even that case work without std::move in C++23, and
GCC and Clang already accept it without std::move in C++20 mode (even though
it's not listed as a defect report).  I think that in these modes it's
impossible to need the std::move, so it's reasonable to issue the warning,
although it might make the most sense to issue a single, generic warning like
"std::move is either useless or harmful here depending on instantiation".

> Thanks for your comments and sorry if I'm still not getting your point.

Thank you for trying to work past my first unclear explanation.

[Bug c++/89780] -Wpessimizing-move is too agressive with templates and recommends pessimization

[herring at lanl dot gov via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89780

--- Comment #8 from S. Davis Herring  ---
I looked at P2266R3 again; it claims that the conversion function case (in #7)
is actually covered by P1825R0.  I think that case is questionable, since it
still refers to "overload resolution to select the constructor for the copy"
and there's no constructor involved when a conversion function is used.  (In
particular, it isn't the case that the A object is converted to a Dest
temporary that is then used as the argument to Dest(Dest&&), since that would
be a second user-defined conversion.)  If we consider the intent in P1155R3,
though, it's pretty clear that that's just a wording oversight, so it's not
unreasonable that GCC and Clang (but not ICC) accept

  template Dest withMove();

in C++20 mode.  That means that we don't have to distinguish C++20 and C++23
for this discussion (at least outside of weirder cases like returning a
reference).

[Bug c++/103876] Parameter pack not expanded in lambda within static_assert in a fold-expression of a lambda

[herring at lanl dot gov via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103876

S. Davis Herring  changed:

   What|Removed |Added

 CC||herring at lanl dot gov

--- Comment #2 from S. Davis Herring  ---
Probably the same bug from a simpler (and C++17-compatible) case:

template
void f(const TT &...tt) {
[tt...]() {
([tt] {},...);
}();
}

:4:13: error: parameter packs not expanded with '...':
4 | ([tt] {},...);
  | ^
:4:13: note: 'tt'

[Bug c++/59256] qualified name in friend function declaration doesn't match previous declaration in inline namespace

[herring at lanl dot gov via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59256

S. Davis Herring  changed:

   What|Removed |Added

 CC||herring at lanl dot gov

--- Comment #14 from S. Davis Herring  ---
(In reply to Jonathan Wakely from comment #0)
> I think the qualified name detail::f should find ::detail::v7::f

In case it helps, this is now unambiguously the case ([decl.meaning]/2.2 in the
current draft describes the lookup, but here it's just ordinary qualified
lookup).

[Bug c++/44402] Doesn't allow friend declarations using a typedef for function type

[herring at lanl dot gov via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44402

S. Davis Herring  changed:

   What|Removed |Added

 CC||herring at lanl dot gov

--- Comment #1 from S. Davis Herring  ---
Current trunk still rejects this, but now produces

:3:21: error: invalid use of qualified-name 'A::f'
3 | struct B { friend F A::f; };
  | ^

[Bug c++/106756] New: Overbroad friendship for nested classes

[herring at lanl dot gov via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106756

Bug ID: 106756
   Summary: Overbroad friendship for nested classes
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: herring at lanl dot gov
  Target Milestone: ---

Sometime since 12.2, GCC has started accepting

struct A {
  struct B {
friend int f(B*) {return i;}
  };
private:
  static int i;
};

despite the express limitation in [class.nest]/4 (/3 in the latest draft). 
(Current Clang also accepts it, but ICC and MSVC do not.)

[Bug c++/106756] Overbroad friendship for nested classes

[herring at lanl dot gov via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106756

--- Comment #2 from S. Davis Herring  ---
(In reply to Jonathan Wakely from comment #1)
> "Declaring a class to be a friend implies that private and protected 
> members
> of the class granting friendship can be named in the base-specifiers and
> member declarations of the befriended class."
> 
> A hidden friend is a syntactic member-declaration, but is it a "member
> declaration"?

That argument doesn't quite apply here: B is the class granting friendship, but
it's A's member being accessed.  To allow this, we'd have to say that B's
friendship gives f access to everything to which B has access, but that would
just be transitive friendship, which is known to be wrong.

That said, one can make a similar argument along the lines of "B is a
member-declaration of A, and so f is part of a member-declaration itself",
which puts us back on the old question of whether it matters whether the friend
is defined inside the class.  Indeed, GCC still rejects the example modified to
use

int f(A::B*) {return A::i;}

but that's an even stronger contradiction with [class.nest]/4 (which uses
"defined within a nested class").

[Bug c++/12228] [DR 244/399] syntax error calling a qualified template dtor

[herring at lanl dot gov via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12228

S. Davis Herring  changed:

   What|Removed |Added

 CC||herring at lanl dot gov

--- Comment #6 from S. Davis Herring  ---
CWG399 was resolved by P1787R6
.  All of
these definitions of foo are valid, although BT and CA will be found during
instantiation only if the template arguments provide them as members.

[Bug c++/95849] Universal forwarding constructor inheritance resolution issue

[herring at lanl dot gov via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95849

S. Davis Herring  changed:

   What|Removed |Added

 CC||herring at lanl dot gov

--- Comment #1 from S. Davis Herring  ---
This is CWG2356
; GCC (along
with Clang) is correct.

[Bug c++/66671] Failure to create a new family of templates for template alias

[herring at lanl dot gov via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66671

S. Davis Herring  changed:

   What|Removed |Added

 CC||herring at lanl dot gov

--- Comment #2 from S. Davis Herring  ---
CWG1286 suggests that perhaps such a trivial alias template as Z ought to
actually be interchangeable with Y.

[Bug c++/107906] New: Function template specialization given weak rather than local symbol

[herring at lanl dot gov via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107906

Bug ID: 107906
   Summary: Function template specialization given weak rather
than local symbol
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: herring at lanl dot gov
  Target Milestone: ---

Current trunk, given 

  template using X=int;
  namespace {
template using Y=int;
  }

  template class Q> void f() {}
  template void f();

  void (*fp)()=f;

emits weak symbols for both specializations of f, despite the fact that a
different "void f<(anonymous namespace)::Y>()" might be defined in another
translation unit (perhaps as an explicit specialization).

[Bug c++/107906] linkage of template not taken into account

[herring at lanl dot gov via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107906

--- Comment #3 from S. Davis Herring  ---
Thanks for identifying the true common thread.

> That is not a specialization, that is an instantiation.

The standard uses specialization for every "version" of a template; some are
just "explicit specializations".  It uses (explicit/implicit) instantiation
only for the process of creating one.  (I realize that just about no one else
uses the words that way.)

[Bug c++/90493] const variable template specialization is always local

[herring at lanl dot gov via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90493

--- Comment #4 from S. Davis Herring  ---
(In reply to Jonathan Wakely from comment #3)
> Reduced to show just the rejects-valid part:
> 
> template  extern const int foo = 41;
> // this is an error:
> // error: explicit template specialization cannot have a storage class
> template <> extern const int foo = 42;

This code is ill-formed ([temp.expl.spec]/2) and is nonsensical because linkage
doesn't pertain to template specializations ([temp.type]/1).  (Obviously at the
assembly level there are global and local symbols for certain template
specializations, but their status is determined by the linkage of the template
and sometimes by the template arguments.)

As such, I'm not sure this is distinct from 96523.

[Bug c++/115207] [constexpr] constexpr assignment rejected as non const on self-assignment test

[herring at lanl dot gov via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115207

S. Davis Herring  changed:

   What|Removed |Added

 CC||herring at lanl dot gov

--- Comment #1 from S. Davis Herring  ---
This looks like yet another duplicate of 85944.

[Bug c++/61754] [C++1y] [[deprecated]] attribute warns annoyingly compared to __attribute__((deprecated))

[herring at lanl dot gov via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61754

S. Davis Herring  changed:

   What|Removed |Added

 CC||herring at lanl dot gov

--- Comment #8 from S. Davis Herring  ---
This also strikes in cases like

  struct [[deprecated]] S {};
  struct T {[[deprecated]] S *backwards() const;};
  [[deprecated]] inline bool f(T t) {return t.backwards();}

where the whole interface is deprecated.  Even given the assumption that T's
author controls f, T can't provide a non-deprecated alternative to T::backwards
because its declaration would already provoke a warning.

Clang and ICC don't warn here, although MSVC issues two.

[Bug c++/91317] [7/8/9/10 Regression] false-positive maybe-uninitialized warning in destructor with placement new

[herring at lanl dot gov via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91317

S. Davis Herring  changed:

   What|Removed |Added

 CC||herring at lanl dot gov

--- Comment #4 from S. Davis Herring  ---
My understanding is that code like this is just inherently unsafe in the
presence of exceptions: the old U's lifetime ends as soon as the constructor
call begins, without running its destructor ([basic.life]/5), and if a() throws
the lifetime of the new U never begins (/1.2), so the automatic destructor call
is UB (/9).

I'd want a warning for any such reinitialization where the potential exception
would definitely destroy the stranded object, and probably even if another
destructor might intervene and terminate the program.  More difficult would be
to handle the case of catching such an exception and trying to resurrect the
object again, possibly via a non-throwing constructor.

[Bug c++/112318] Deprecated move ctor does not trigger -Wdeprecated-declarations when creating a std::optional

[herring at lanl dot gov via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112318

S. Davis Herring  changed:

   What|Removed |Added

 CC||herring at lanl dot gov

--- Comment #4 from S. Davis Herring  ---
The issue is really broader than just "declaration or use is not in -isystem";
since it's standard practice to use -isystem for third-party headers (to avoid
"personal" warnings like -Wparentheses taking effect in code not written to
them), this still fails to issue a warning if `foo` comes from such a header. 
(But the warning works when foo's author checks for it in their own unit
tests...)

It's a very hard problem in general.  A colleague pointed me at Perl's carp,
which attempts to identify whose "fault" a diagnostic is
.  The package rule there could even
be applied to C++20 modules, or perhaps to top-level namespaces in a pinch. 
Beyond that, it might be worthwhile to presume that any warning triggered by a
type- or value-dependent expression should be associated (for -Wsystem-headers
purposes) with the point of instantiation, although I'm sure there would be
some false positives from that.  (There needs to be a better-than-#pragma way
to suppress individual deprecation warnings for such cases.)

[Bug c++/118760] New: Alias template in dependent base used via injected-class-name incorrectly rejected

[herring at lanl dot gov via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118760

Bug ID: 118760
   Summary: Alias template in dependent base used via
injected-class-name incorrectly rejected
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: herring at lanl dot gov
  Target Milestone: ---

GCC trunk rejects

template
struct base {
  template using id=T;
};
template
struct derived : base {
  typename derived::/*template*/ id i;
};
derived<1> x;

complaining that the type of derived<1>::i is not a class type.  This is true,
of course, but hardly an error.  (The commented-out template is for Clang
comparison; it was rendered unnecessary by CWG1710, but Clang still erroneously
requires it.)

[Bug c++/16233] unhelpful error message when "template" is omitted

[herring at lanl dot gov via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16233

S. Davis Herring  changed:

   What|Removed |Added

 CC||herring at lanl dot gov

--- Comment #12 from S. Davis Herring  ---
-Wmissing-template-keyword is now on by default and helps here, even if the
actual error message is still baroque.