https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92727
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |diagnostic
Severity|normal |enhancement
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to David Brown from comment #0)
> Would it be possible to hide the messages concerning the allocator here?
I don't see how. It's the allocator that tries to use the X(const X&) copy
constructor. Why would you want to hide it?
> In
> general, would it be possible to hide the messages that deal with template
> parameters that are unchanged from the default?
Can you clarify what you mean? Nothing in this error has anything to do with
default template arguments. You'll get exactly the same error with
std::vector<X, acme::my_custom_allocator<X>>.
> That would let the user see
> messages that are relevant to the code /they/ have written, rather than
> implementation details in the libraries and headers.
While that seems a noble goal, I don't think "hide the messages concerning the
allocator" or "hide the messages that deal with template parameters that are
unchanged from the default" get anywhere near that goal.
> Even better, in this case, would be a hint that the user needs a std::move,
> as shown in line B.
Where should the compiler suggest that move? How does it know whether the
missing std::move should be in main(), or inside std::vector::push_back, or
inside allocator::construct?
A reasonable heuristic would be to assume code inside system headers is
correct, and that the code using those system headers is at fault, but it's
still going to suggest the wrong place often.
A better one would be to assume system headers are correct, and not suggest
adding it anywhere that already uses std::forward, because that's probably
generic code dealing with perfect forwarding, and the move should have been in
the caller of *that* code.
And you don't want to suggest adding std::move to a const value, because that
won't help.
The general problem is that inserting a std::move at some point in the call
graph can completely change everything after that point, and so won't
necessarily even reach the code that gave an error. Is that a "fix"? It's
impossible to know without grokking the code.
