https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119962
--- Comment #4 from 康桓瑋 ---
(In reply to Andrew Pinski from comment #2)
> https://eel.is/c++draft/range.lazy.split.outer
>
>
> Testcase from godbolt:
> ```
> #include
>
> struct I {
> int x;
> using difference_type = std::ptrdiff_t;
>
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
It looks like libstdc++'s __maybe_present_t is always missing initialization,
which leads to failure to make some constexpr singular iterators:
https://godbolt.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109162
--- Comment #23 from 康桓瑋 ---
(In reply to Tomasz Kamiński from comment #22)
> > That is highly intentional to fix incorrect formatting when the container
> > is a string. See https://cplusplus.github.io/LWG/issue3881
>
> I am well aware of thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109162
--- Comment #21 from 康桓瑋 ---
> Furthermore the standard specifies these formatters as delegating to
> formatter, charT>, which in turn
> delegates to range_formatter. This patch avoids one level of indirection,
> and dependency o
++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
Why is the GCC Bugzilla become so slowly lately???
This is high duplicate of PR 119906:
#include
#include
template
struct view {
R r;
auto foo(R&) -> std::bool_c
l
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
Not sure if there is already a similar duplicate.
https://godbolt.org/z/W8sbx3hnn
#include
#include
template
struct view {
R r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119861
--- Comment #1 from 康桓瑋 ---
..which should not:
#include
struct Map {
std::pair* begin();
std::pair* end();
};
template<>
constexpr auto std::format_kind = std::range_format::map;
int main() {
std::formatter fmt;
fmt.set_separator("
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119820
--- Comment #1 from 康桓瑋 ---
An example I can think of could be:
struct I {
using difference_type = int;
using value_type = char;
value_type operator*() const;
I& operator++();
I operator++(int);
I& operator--();
I operator--(int);
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
The format ranges make a subrange via ranges::subrange __sub(__first, __first +
__n);, where __n is a size_t
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
This is the sibling of PR119748:
https://godbolt.org/z/Mv184YGo8
#include
int main() {
volatile char vc[4] = {'a', 'b', 'c',
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119748
--- Comment #1 from 康桓瑋 ---
The _S_copy_range(pointer __p, _Rg&& __rg, size_type __n) help committed
yesterday also needs to be fixed for the contiguous_range branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055
--- Comment #26 from 康桓瑋 ---
(In reply to Jonathan Wakely from comment #25)
> If we can't use range-based 'for' with ranges then we've taken a wrong turn
> somewhere.
>
> I did test them in e.g. std/ranges/access/begin.cc so we know that
> rang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055
--- Comment #24 from 康桓瑋 ---
(In reply to Jonathan Wakely from comment #22)
> but they deserve to break.
I agree with that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055
--- Comment #21 from 康桓瑋 ---
(In reply to Jonathan Wakely from comment #20)
> Does it matter? By design, ranges::begin does the same things as range-based
> for (handles arrays first, then looks for member begin(), then looks for ADL
> begin).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055
--- Comment #19 from 康桓瑋 ---
(In reply to GCC Commits from comment #18)
> The master branch has been updated by Jonathan Wakely :
>
> https://gcc.gnu.org/g:882d3b319dbf50ae64080731a1398031c100b7c7
>
> commit r15-9378-g882d3b319dbf50ae64080731a
ibstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
The following should be well-formed since C++23.
#include
#include
int main() {
std::array a;
std::tuple<> t;
auto eq = (t == a);
auto cmp = (t <
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119620
--- Comment #5 from 康桓瑋 ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to 康桓瑋 from comment #0)
> > I don't know why the standard sometimes constrains emplace(), sometimes only
> > constrains insert(), and sometimes constrains neit
++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
This might be seen as *asking for trouble* bug report:
Currently, in libstdc++, flat_set::emplace requires
is_constructible_v, which is not required by the
standard.
https
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101587
--- Comment #11 from 康桓瑋 ---
(In reply to Jonathan Wakely from comment #10)
> (In reply to 康桓瑋 from comment #9)
> > Still need casting the return difference type from __mindist, I think?
>
> Ah yes, we need to cast it back to the type of the fi
ormal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
#include
struct Boolean {
Boolean(Boolean&&) = delete;
operator bool() const;
};
struct Object {
: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
The following code produces:
Killed - processing time exceeded
Program terminated with signal: SIGKILL
Compiler returned: 143
when using -O2.
#include
#include
#include
#include
#include
#include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101587
--- Comment #9 from 康桓瑋 ---
(In reply to GCC Commits from comment #8)
> The master branch has been updated by Jonathan Wakely :
>
> https://gcc.gnu.org/g:f4b6acfc36fb1f72fdd5bf4da208515e6495a062
>
> commit r15-8980-gf4b6acfc36fb1f72fdd5bf4da20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116399
--- Comment #20 from 康桓瑋 ---
(In reply to Jonathan Wakely from comment #19)
> We could do this, and rely on the fact that the number of aliases is always
> small so that we can claim it's O(1):
>
> --- a/libstdc++-v3/include/std/text_encoding
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116399
--- Comment #18 from 康桓瑋 ---
> The random-access-non-sized ranges in the standard are currently only
> infinite ranges such as views::iota(0). Random access is useful for these
> ranges because we can random access any place without worrying abo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116399
--- Comment #17 from 康桓瑋 ---
(In reply to Jonathan Wakely from comment #15)
> (In reply to 康桓瑋 from comment #13)
> > I'm not sure it's reasonable or trivial for alias_view to be sized_range,
>
> I don't think it is necessary. Is there a use cas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116399
--- Comment #13 from 康桓瑋 ---
(In reply to Jonathan Wakely from comment #12)
> Implementation-defined means the implementation must define it (and document
> it).
>
> If the implementation says the types are different, then they're different,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119415
--- Comment #14 from 康桓瑋 ---
I believe the correct way should be:
else if constexpr (ranges::common_range<_Rg> &&
requires {
requires
derived_from>::iterator_category,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119415
--- Comment #13 from 康桓瑋 ---
(In reply to Tomasz Kamiński from comment #12)
> I have realized that with the resolution of the
> https://cplusplus.github.io/LWG/lwg-defects.html#3749, you can run into this
> problem by doing:
>
> auto r = std::v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119415
--- Comment #11 from 康桓瑋 ---
> Use __cpp17_input_iterator can still produce hard errors in some edge cases.
With "hard errors", I mean the following:
struct I {
using difference_type = int;
using value_type = int;
int operator*() const;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119415
--- Comment #10 from 康桓瑋 ---
(In reply to Tomasz Kamiński from comment #9)
> > Hum, meeting Cpp17LegacyIterator requirements does not mean it is a C++17
> > input iterator, only iterator_traits::iterator_category represents its
> > category, s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119415
--- Comment #8 from 康桓瑋 ---
(In reply to GCC Commits from comment #6)
> The master branch has been updated by Tomasz Kaminski :
>
> https://gcc.gnu.org/g:4d1b19695669e6c67b9c3df07673bc22cae3a662
>
> commit r15-8879-g4d1b19695669e6c67b9c3df0767
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119415
--- Comment #5 from 康桓瑋 ---
(In reply to Tomasz Kamiński from comment #4)
> If want to support user-defined containers, I think we should check if
> iterator_traits::iterator category exists, before calling
> insert(Iterator, Iterator) overload.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
GCC rejects the following valid code:
#include
#include
template
struct simd {
template
constexpr simd(R&&) { }
};
template
simd(R&& r) ->
simd,
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
#include
int main() {
std::flat_map m1, m2;
std::erase_if(m1, [](auto) { return true; }); // error
}
https://godbolt.org/z/P4cTdzo69
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119427
--- Comment #2 from 康桓瑋 ---
Also, erase_if should not use ranges::remove_if, since that would support
member pointers via std::invoke, which the standard currently disallows.
This seems like an enhancement, though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119427
--- Comment #1 from 康桓瑋 ---
flat_set has the same issue.
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
Bug 118156 fixes the non-common range issue, and one of the new branches is:
else if constexpr (ranges::common_range<_Rg>)
: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
This led to a hard error in the following code with -std=gnu++23:
auto r = std::views::iota(__int128(0))
| std
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
#include
struct S { bool has_value() const; };
namespace std::ranges {
template, iterator_t<_Vp>> _Pr
++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
/ranges#L9351:
else if constexpr (__detail::__is_ref_view<_Tp>
&& constant_range)
return ref_view(static_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115218
--- Comment #9 from 康桓瑋 ---
(In reply to Patrick Palka from comment #8)
> Fixed, thanks!
The fix for LWG 4082 is the missing viewable_range constraint for one pack
case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119022
康桓瑋 changed:
What|Removed |Added
CC||hewillk at gmail dot com
--- Comment #2 from 康桓瑋
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115209
--- Comment #7 from 康桓瑋 ---
(In reply to 康桓瑋 from comment #6)
> (In reply to Patrick Palka from comment #5)
> > (In reply to 康桓瑋 from comment #4)
> > > > Our concat_view implementation is accidentally based off of an older
> > > > revisi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115209
--- Comment #6 from 康桓瑋 ---
(In reply to Patrick Palka from comment #5)
> (In reply to 康桓瑋 from comment #4)
> > > Our concat_view implementation is accidentally based off of an older
> > > revision of the paper, P2542R7 instead of R8. A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115209
--- Comment #4 from 康桓瑋 ---
> Our concat_view implementation is accidentally based off of an older
> revision of the paper, P2542R7 instead of R8. As far as I can tell the
> only semantic change in the final revision is the relaxed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115218
--- Comment #2 from 康桓瑋 ---
(In reply to Patrick Palka from comment #1)
> Does this also mean the iterator's default ctor needs a
> default_initializable<_Vs...[0]> constraint?
The variant constructor already has such a constraint.
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
#include
#include
int main() {
std::flat_set m;
m.insert_range(std::views::iota(0) | std::views::take(5));
}
https://godbolt.org/z/Wzah6Ms67
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
possibly-const-range requires that the template parameter R satisfy
input_range, which libstdc++ misses, which leads to the following hard error:
#include
struct
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
auto
yield_value(const _Yielded_deref& __val)
noexcept (is_nothrow_constructible_v<_Yielded_
++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
The following gives: Program terminated with signal: SIGSEGV, not sure what
happens, so let me assume for now that this is a bug (either in the language or
in the library).
#include
std
: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
template
constexpr auto
operator() [[nodiscard]] (_Iter __i, iter_difference_t<_Iter> __n)
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
https://godbolt.org/z/Mh64vqGcs
#include
int main() {
static const std::regex rgx{"hello"};
}
compil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111861
--- Comment #4 from 康桓瑋 ---
(In reply to Patrick Palka from comment #3)
> (In reply to 康桓瑋 from comment #2)
> > (In reply to Patrick Palka from comment #1)
> > > Interesting, I guess 'auto x = *iter;' should never be done in generic
> > > code
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
Unlike vector::assign_range which requires assignable_from> is true, this means that ranges::copy is not
necessarily well-formed for vector::insert_range:
#incl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111861
--- Comment #2 from 康桓瑋 ---
(In reply to Patrick Palka from comment #1)
> Interesting, I guess 'auto x = *iter;' should never be done in generic code
> then?
Yap, even 'range_value_t x = *iter;'.
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
When sized_sentinel_for<_Sent, _Out> is true, ranges::fill dispatches
ranges::fill_n(__first, __len, __value) while __first is not guaranteed to be
copyable.
#i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115098
--- Comment #3 from 康桓瑋 ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to 康桓瑋 from comment #1)
> > std::bitset has similar issues:
> >
> > #include
> >
> > std::bitset<1> bitset;
> > typename std::bitset<1>::reference bit_ref(b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116399
--- Comment #10 from 康桓瑋 ---
(In reply to Jonathan Wakely from comment #9)
> Currently aliases_view is allowed to be a common range, but not required to
> be.
>
> If we specify that its sentinel type is std::default_sentinel, that would
> requi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116399
--- Comment #8 from 康桓瑋 ---
(In reply to Jonathan Wakely from comment #7)
> "Note that this view is not common_range because it can be implemented more
> efficiently
> without that requirement, and, being copyable, it can be adapted into one."
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116399
--- Comment #5 from 康桓瑋 ---
(In reply to Jonathan Wakely from comment #4)
> Thanks! I'll submit an LWG issue to add something saying there's an
> unspecified constructor, or just say explicitly that it's not default
> constructible.
Not sure it
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
text.encoding.aliases] indicates that text_encoding::aliases_view is an empty
struct, which suggests it is default-constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115914
--- Comment #2 from 康桓瑋 ---
(In reply to Andrew Pinski from comment #1)
> I suspect this is a dup of bug 113460.
Definitely.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
#include
#include
#include
#include
template
auto concat(Rs&&... rs) -> std::generator {
(co_yield std::ranges::ele
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115846
--- Comment #8 from 康桓瑋 ---
(In reply to 康桓瑋 from comment #7)
> (In reply to Jonathan Wakely from comment #6)
> > (In reply to Andrew Pinski from comment #1)
> > > I think it is due to:
> > > include/std/optional: _GLIBCXX20_CONSTEXPR ~_Stor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115846
--- Comment #7 from 康桓瑋 ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to Andrew Pinski from comment #1)
> > I think it is due to:
> > include/std/optional: _GLIBCXX20_CONSTEXPR ~_Storage() { }
> >
> > Which was done in r12-4
mal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
#include
#include
// static_assert([] {
// std::unique_ptr p; // non-constant condition for static assertion
// return t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115799
--- Comment #8 from 康桓瑋 ---
(In reply to Jonathan Wakely from comment #7)
> Fixed now, thanks for the reports.
Thanks for the quick fix. There may be another potential issue that I don't
know if it is worth mentioning.
When the difference_typ
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
template
struct overloaded : Ts... { };
// explicit deduction guide (not needed as of C++20)
// template
// overloaded(Ts...) -> overloaded;
int main() {
aut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115799
--- Comment #3 from 康桓瑋 ---
(In reply to Tamar Christina from comment #2)
> I also get an ICE related:
>
> /opt/buildAgent/temp/buildTmp/toolchain/include/c++/15.0.0/bits/stl_algo.h:
> 3873:38: error: no match for 'operator+' (operand types are
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
#include
#include
auto get_n = [](Tuple&am
ormal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
ranges_util.h#L505:
if constexpr (is_same_v<_Proj, identity>)
if constexpr(__can_use_memchr_fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115792
--- Comment #7 from 康桓瑋 ---
(In reply to Andrew Pinski from comment #6)
> So I looked into the change for clang:
> https://github.com/llvm/llvm-project/commit/
> 0620e6f4b76a9725dbd82454d58c5a68a7e47074
>
> And they didn't add a testcase for th
++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
int main() {
auto l = [] throw () {};
l();
}
https://godbolt.org/z/GejGeKzjd
Other compilers consider it a syntax error. I currently don't know who is
right.
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
This seems like 15 regressions and may related to the
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
constexpr
iterator(iterator __it)
requires _Const && (convertible_to, it
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
libstdc++'s views::concat always requires concat_view(rs...) to be well-formed
which does not fully conform with the wording as R does not need to satisfy
concatable
: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
It seems that R8 is the final version. Not sure why libstdc++ refers to R7,
which makes some updates of R8 not integrated
: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
..which can be an regression:
#include
struct Bool {
operator bool();
Bool(const Bool&) = delete;
};
st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115098
--- Comment #1 from 康桓瑋 ---
std::bitset has similar issues:
#include
std::bitset<1> bitset;
typename std::bitset<1>::reference bit_ref(bitset, 0); // well-formed in
libstdc++
https://godbolt.org/z/T4qvv8TcG
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
..which shouldn't because [vector.bool.pspc] specifies that its default
constructor is private.
#include
typename std::vector::ite
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
#include
#include
#include
std::string fn() {
std::istringstream is {"bob"};
auto beg = std::istreambuf_iterator(is);
auto end = std::istreambu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115046
--- Comment #1 from 康桓瑋 ---
Oh, maybe this is just because MSVC does not use std::optional but uses
_Defaultabox.
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
I seriously doubt this is a more practical example of LWG 3986 since join_view
has a std::optional member to store the iterator, but I'm not sure about
wh
ponent: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
This is related to the PR38.
#include
int main() {
std::views::adjacent_transform<0>(std::views::single(0), []{}); // hard error
in libstdc++
}
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
Consider the following:
#include
struct S {
S() = default;
S(S&&) = default;
};
S s;
std::rang
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
Suppose I misspelled an extra colon for the namespace
(https://godbolt.org/z/q3b7531q3):
#include
#include
using Tuple = std::tuple;
GCC
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
https://godbolt.org/z/v6M35zMa4
There is a typo here, I missed an underscore:
template requires Const_
struct S;
S s;
The error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103924
--- Comment #4 from 康桓瑋 ---
(In reply to Patrick Palka from comment #2)
> *** Bug 114530 has been marked as a duplicate of this bug. ***
That's my lost memory.
; member in constant expression
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114477
--- Comment #6 from 康桓瑋 ---
(In reply to Jiang An from comment #5)
> (In reply to 康桓瑋 from comment #0)
> > Since P3059R0 is closed (although I feel bad about this)
>
> BTW, now I think this is somehow unfortunate.
> P3059 behaved like a follow-
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
Since P3059R0 is closed (although I feel bad about this), this suggests that
libstdc++ may need to
: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
This is the sibling of Bug 113788.
template struct S {} ;
S<0> s{};
https://godbolt.org/z/GbdqW9zee
Thank you.
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
struct S {
int i = 42;
constexpr auto f() {
return [this](this auto) {
return this-&g
++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
struct S {
auto f(this auto self...) { }
};
int main() {
S{}.f();
}
https://godbolt.org/z/a81WPW65f
GCC rejects the above code with:
:2:10: error: an explicit object
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
GCC accepts the following:
struct S {
int a, b;
};
int main() {
S s = {1, 2};
this auto& [a, b] = s;
return b;
}
Thanks.
https://godbolt.org/z/34xTee6sx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113640
--- Comment #1 from 康桓瑋 ---
Noted that changing `this auto self` to `this auto&& self` will get the
expected results
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
#include
int main() {
auto l = [](this auto self, int n) {
std::cout << n << " ";
return self
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113629
--- Comment #2 from 康桓瑋 ---
more reduced:
struct Base {
operator int(this auto&&) {
return 42;
}
};
int main() {
Base b;
// return static_cast(Base{}); // ok
return static_cast(b); // error
}
https://godbolt.org/z/qGrbf4rj7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113629
--- Comment #1 from 康桓瑋 ---
test:
https://godbolt.org/z/jdz3ejohv
1 - 100 of 540 matches
Mail list logo
