On Tue, Oct 5, 2021 at 1:13 PM <paul.robin...@sony.com> wrote: > According to https://en.cppreference.com/w/cpp/language/function the > cv-qualifier is allowed only on non-static member functions, which are > exactly the ones that have an implicit this-pointer parameter. > > *cv* > > - > > const/volatile qualification, only allowed in non-static member function > declarations > > Are cv-qualified free functions or static member functions a GCC > extension? If so, then doing what GCC does seems like exactly the right > thing to do. It falls within the “permissive” nature of DWARF to do that. > I don’t know that the DWARF standard should say anything special about it, > though. >
Ah, sorry, should've clarified earlier - this is only a property of function types, not of the types of functions... because C++ is fun like that. You can't create a free function like "void f() const { }" but you can create a function type, used for instance in a template type argument which has a const qualifier: template<typename T> void f1(); ... f1<void () const>(); - you can't even create a function pointer of this const qualified function type: "void (*)() const" is not a valid type, for instance. See for instance this C++ standards proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0288r4.html#Specification - which uses a std::function-like template, but with the const qualifier on the function type parameter to determine whether the functor is mutable or not. (so "std::any_invocable<void()>" is only callable when the object is non-const, but "std::any_invocable<void()const>" is callable even on if it's a const object) > --paulr > > > > *From:* Dwarf-Discuss <dwarf-discuss-boun...@lists.dwarfstd.org> *On > Behalf Of *David Blaikie via Dwarf-Discuss > *Sent:* Tuesday, October 5, 2021 3:12 PM > *To:* DWARF Discuss <dwarf-discuss@lists.dwarfstd.org> > *Subject:* [Dwarf-Discuss] Inconsistency of C++ member function qualifiers > > > > C++ member functions can be qualified in a number of ways - classic CV > (const and volatile) qualifiers, and since C++11, lvalue (&) and rvalue > (&&) reference qualifiers. Details here: > https://en.cppreference.com/w/cpp/language/member_functions > <https://urldefense.com/v3/__https:/en.cppreference.com/w/cpp/language/member_functions__;!!JmoZiZGBv3RvKRSx!tqhSDxClelx78nUz9oi9l27R5fYiWC6bR-gPJvMTM8FbJ-K2FSVDb2wi9pRr3rfbCg$> > > A note on 5.10, page 127 says: > > "C++ const-volatile qualifiers are encoded as part of the type of the > “this”-pointer. C++11 reference and rvalue-reference qualifiers are encoded > using the DW_AT_reference and DW_AT_rvalue_reference attributes, > respectively. See also Section 5.7.8 on page 120." > > Though this appears to be inadequate, because C++ allows these qualifiers > on any function type - even one without a first parameter necessary to > carry the const/volatile qualifiers. > > eg: > template<typename T> > struct t1 { }; > > t1<void () const> v1; > > GCC implements this type by using DW_TAG_const_type around a > DW_TAG_subroutine_type. I've implemented the same behavior in Clang > recently. > > For actual member functions (eg: void (some_type::*)() const) both Clang > and GCC put the const type on the artificial first parameter rather than by > wrapping the type in DW_TAG_const_type. > > > Does this seem acceptable, should we do something different to unify the > representation between these two cases? Should we add some more > non-normative text in 5.10/p127? > >
_______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org