public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/101739] New: Some function parameters in <ranges> missing uglify
@ 2021-08-03 6:32 hewillk at gmail dot com
2021-08-31 17:05 ` [Bug libstdc++/101739] " redi at gcc dot gnu.org
` (5 more replies)
0 siblings, 6 replies; 7+ messages in thread
From: hewillk at gmail dot com @ 2021-08-03 6:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101739
Bug ID: 101739
Summary: Some function parameters in <ranges> missing uglify
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
Hey, Patrick, I found that you uglify some function parameters in yesterday’s
r12-2676 to prevent user-defined macros from polluting names.
There are also some function parameters missing uglifying in <ranges>, it will
be more friendly to users if they are underlined:
--- include/std/ranges
+++ include/std/ranges
@@ -1994,8 +1994,8 @@ namespace views::__adaptor
take_view() requires default_initializable<_Vp> = default;
constexpr
- take_view(_Vp base, range_difference_t<_Vp> __count)
- : _M_count(std::move(__count)), _M_base(std::move(base))
+ take_view(_Vp __base, range_difference_t<_Vp> __count)
+ : _M_count(std::move(__count)), _M_base(std::move(__base))
{ }
constexpr _Vp
@@ -2180,8 +2180,8 @@ namespace views::__adaptor
= default;
constexpr
- take_while_view(_Vp base, _Pred __pred)
- : _M_pred(std::move(__pred)), _M_base(std::move(base))
+ take_while_view(_Vp __base, _Pred __pred)
+ : _M_pred(std::move(__pred)), _M_base(std::move(__base))
{ }
constexpr _Vp
@@ -3782,8 +3782,8 @@ namespace views::__adaptor
elements_view() requires default_initializable<_Vp> = default;
constexpr explicit
- elements_view(_Vp base)
- : _M_base(std::move(base))
+ elements_view(_Vp __base)
+ : _M_base(std::move(__base))
{ }
constexpr _Vp
@@ -3903,14 +3903,14 @@ namespace views::__adaptor
_Iterator() requires default_initializable<iterator_t<_Base>> =
default;
constexpr explicit
- _Iterator(iterator_t<_Base> current)
- : _M_current(std::move(current))
+ _Iterator(iterator_t<_Base> __current)
+ : _M_current(std::move(__current))
{ }
constexpr
- _Iterator(_Iterator<!_Const> i)
+ _Iterator(_Iterator<!_Const> __i)
requires _Const && convertible_to<iterator_t<_Vp>,
iterator_t<_Base>>
- : _M_current(std::move(i._M_current))
+ : _M_current(std::move(__i._M_current))
{ }
constexpr const iterator_t<_Base>&
Thank you again for your great contribution to <ranges>. :)
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libstdc++/101739] Some function parameters in <ranges> missing uglify
2021-08-03 6:32 [Bug libstdc++/101739] New: Some function parameters in <ranges> missing uglify hewillk at gmail dot com
@ 2021-08-31 17:05 ` redi at gcc dot gnu.org
2021-08-31 17:20 ` hewillk at gmail dot com
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: redi at gcc dot gnu.org @ 2021-08-31 17:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101739
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
These changes are not strictly necessary.
"base" is a reserved name, because of move_iterator::base() etc.
and "i" is a reserved name, because of operator""i() in <complex>.
So users cannot define those as macros, and so it's safe for us to use them.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libstdc++/101739] Some function parameters in <ranges> missing uglify
2021-08-03 6:32 [Bug libstdc++/101739] New: Some function parameters in <ranges> missing uglify hewillk at gmail dot com
2021-08-31 17:05 ` [Bug libstdc++/101739] " redi at gcc dot gnu.org
@ 2021-08-31 17:20 ` hewillk at gmail dot com
2021-08-31 18:24 ` redi at gcc dot gnu.org
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: hewillk at gmail dot com @ 2021-08-31 17:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101739
--- Comment #2 from 康桓瑋 <hewillk at gmail dot com> ---
(In reply to Jonathan Wakely from comment #1)
> These changes are not strictly necessary.
>
> "base" is a reserved name, because of move_iterator::base() etc.
>
> and "i" is a reserved name, because of operator""i() in <complex>.
>
> So users cannot define those as macros, and so it's safe for us to use them.
Extremely reasonable.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libstdc++/101739] Some function parameters in <ranges> missing uglify
2021-08-03 6:32 [Bug libstdc++/101739] New: Some function parameters in <ranges> missing uglify hewillk at gmail dot com
2021-08-31 17:05 ` [Bug libstdc++/101739] " redi at gcc dot gnu.org
2021-08-31 17:20 ` hewillk at gmail dot com
@ 2021-08-31 18:24 ` redi at gcc dot gnu.org
2021-09-01 11:52 ` hewillk at gmail dot com
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: redi at gcc dot gnu.org @ 2021-08-31 18:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101739
--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
For consistency (and to avoid reports like this one) we might want to uglify
them anyway. But it's not a correctness issue, just stylistic.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libstdc++/101739] Some function parameters in <ranges> missing uglify
2021-08-03 6:32 [Bug libstdc++/101739] New: Some function parameters in <ranges> missing uglify hewillk at gmail dot com
` (2 preceding siblings ...)
2021-08-31 18:24 ` redi at gcc dot gnu.org
@ 2021-09-01 11:52 ` hewillk at gmail dot com
2021-09-01 12:32 ` redi at gcc dot gnu.org
2023-04-12 16:17 ` ppalka at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: hewillk at gmail dot com @ 2021-09-01 11:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101739
--- Comment #4 from 康桓瑋 <hewillk at gmail dot com> ---
(In reply to Jonathan Wakely from comment #3)
> For consistency (and to avoid reports like this one) we might want to uglify
> them anyway. But it's not a correctness issue, just stylistic.
I think I might be the only one who would ask for trouble to report this kind
of issue ;-)
By the way, do you plan to respond to Casey's charges against you? It seems to
me that he mistakenly believes that libstdc++ has a bug.
https://github.com/microsoft/STL/issues/2171#issuecomment-908798422
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libstdc++/101739] Some function parameters in <ranges> missing uglify
2021-08-03 6:32 [Bug libstdc++/101739] New: Some function parameters in <ranges> missing uglify hewillk at gmail dot com
` (3 preceding siblings ...)
2021-09-01 11:52 ` hewillk at gmail dot com
@ 2021-09-01 12:32 ` redi at gcc dot gnu.org
2023-04-12 16:17 ` ppalka at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: redi at gcc dot gnu.org @ 2021-09-01 12:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101739
--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Yes, I need to look into it. He might be right, I'm not sure yet.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libstdc++/101739] Some function parameters in <ranges> missing uglify
2021-08-03 6:32 [Bug libstdc++/101739] New: Some function parameters in <ranges> missing uglify hewillk at gmail dot com
` (4 preceding siblings ...)
2021-09-01 12:32 ` redi at gcc dot gnu.org
@ 2023-04-12 16:17 ` ppalka at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: ppalka at gcc dot gnu.org @ 2023-04-12 16:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101739
Patrick Palka <ppalka at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
CC| |ppalka at gcc dot gnu.org
Target Milestone|--- |13.0
Resolution|--- |FIXED
--- Comment #6 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Looks like the missing uglification has been corrected by
r13-2202-g980e0aa0ce3bdf and r13-2323-g26aafae4e50d1b, so I suppose we could
close this as fixed for GCC 13.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-04-12 16:17 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-03 6:32 [Bug libstdc++/101739] New: Some function parameters in <ranges> missing uglify hewillk at gmail dot com
2021-08-31 17:05 ` [Bug libstdc++/101739] " redi at gcc dot gnu.org
2021-08-31 17:20 ` hewillk at gmail dot com
2021-08-31 18:24 ` redi at gcc dot gnu.org
2021-09-01 11:52 ` hewillk at gmail dot com
2021-09-01 12:32 ` redi at gcc dot gnu.org
2023-04-12 16:17 ` ppalka at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).