https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #27 from Gašper Ažman ---
I think there is an example in the standard that distinguishes those two as
far as overload resolution is concerned.
On Thu, Jan 11, 2024, 21:08 waffl3x at protonmail dot com <
gcc-bugzi...@gcc.gnu.org>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #19 from Gašper Ažman ---
Correct, the use of the capture is the source of the error, not the
instantiation with an unrelated type.
On Sat, Sep 2, 2023, 09:54 waffl3x at protonmail dot com <
gcc-bugzi...@gcc.gnu.org> wrote:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #17 from Gašper Ažman ---
Read through the patch quickly, want to suggest a few tests.
When a lambda has captures, the explicit object parameter is used to get at
them *silently*, if they are related, otherwise the program is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #12 from Gašper Ažman ---
Replies to relevant snippets inline.
That was quite a write-up!
> The only compelling case I can think of for such a thing would be passing a
> pointer type that isn't related by inheritance anyway. That
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #10 from Gašper Ažman ---
Yes, the explicit object parameter always receives the cv-l/r qualified
reference to the object of the call. Implicit conversions are then of
course allowed, same as any other parameter. S* is not that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #5 from Gašper Ažman ---
And of course by "this" I meant support for a default argument on the explicit
object parameter.
We might add it back in the future if we find a usecase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #4 from Gašper Ažman ---
As one of the authors, I can assure you you never need to implement this for
c++23.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110441
--- Comment #2 from Gašper Ažman ---
Some more color from twitter, courtesy of @matthewecross:
Interestingly both "return S::f();" and "auto s = S(); return s.f();" both
pass. It's only when you create a temporary instance of S in the return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110441
Gašper Ažman changed:
What|Removed |Added
CC||gasper.azman at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110380
--- Comment #4 from Gašper Ažman ---
John McFarlane noted that pre-initializing coverage datastructures with the
results of the constexpr-evaluated traces would also be a possible direction.
It does mean the linker needs to then correctly merge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110380
--- Comment #2 from Gašper Ažman ---
-fprofile-constexpr is perfectly fine :), as long as it gets a filename
argument for the output; build automation will be thankful.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110380
Bug ID: 110380
Summary: [feature request] "-pg-constexpr=coverage-output" emit
coverage metrics for constexpr code evaluated at
compile time
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98660
--- Comment #5 from Gašper Ažman ---
s/endif/pragma GCC diagnostic pop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98660
--- Comment #4 from Gašper Ažman ---
@Eric Gallager: yes, the #pragma solution is what I currently use. It is
entirely unsatisfactory, for the reasons described in my original request.
The long-term usefulness of warnings is directly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98660
--- Comment #2 from Gašper Ažman ---
Ivan: indeed, you could use a static cast, or a macro - you're literally just
changing the value category of the expression to its original one. The cast is
safe.
The reason Niebler and friends (including
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98660
Bug ID: 98660
Summary: -Wold-style-cast should not warn on casts that look
like (decltype(x))(x)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
16 matches
Mail list logo
