On Tue, Jan 24, 2017 at 3:43 PM, Alexandre Oliva <aol...@redhat.com> wrote:
> On Jan 24, 2017, Jason Merrill <ja...@redhat.com> wrote:
>> On Mon, Jan 23, 2017 at 7:21 PM, Alexandre Oliva <aol...@redhat.com> wrote:
>>> On Jan 23, 2017, Jason Merrill <ja...@redhat.com> wrote:
>>>
>>>>>>> + If the newly-created namespace is to be an inline namespace, after
>>>>>>> + push_namespace, get the nested namespace decl with
>>>>>>> + get_current_binding_level, pop back to the enclosing namespace,
>>>>>>> + call using_namespace with INLINE_P, and then push to the inline
>>>>>>> + namespace again. */
>>>>>
>>>>>> This seems like unnecessary contortions to expect of the caller
>>>>>> (i.e. GDB). Let's add a new front end function to handle this.
>>>>>
>>>>> Heh, it's really nothing compared with some other contortions required
>>>>> to navigate binding levels, e.g. to reenter a function scope.
>>>>>
>>>>> I didn't want to add redundant functionality to the libcc1 API, and we'd
>>>>> need the ability to separate the introduction or reentry in a namespace,
>>>>> from a using directive with attribute strong. And since inline
>>>>> namespaces use the same implementation as that, I figured it made sense
>>>>> to use the same interface for both.
>>>
>>>>> Besides, push_namespace is called a lot more often than using_namespace,
>>>>> so it makes sense to keep it simpler, and leave the extra parameter for
>>>>> the less common operation.
>>>>>
>>>>> Another argument to keep things as they are is that the inline-ness of a
>>>>> namespace is not a property related with entering the namespace, but
>>>>> rather with how names from it are brought into the other namespace.
>>>
>>>> Well, it's a property of the namespace.
>>>
>>> Even in the case of 'strong' using directives? I didn't think so.
>
>> 'strong' using directives should really go away, they were a brief
>> stop on the way to inline namespaces. We really shouldn't introduce
>> more functionality based on them. I'll add a deprecated warning
>> now...
>
> Ok, but where does that leave us WRT libcc1? Should we make it
> impossible for GDB to convey this construct to libcc1 if it finds it in
> an existing program? (if it is represented in debug information at all)
It isn't represented in the debug information.
> If we make it so, then a new entry point that makes the current
> namespace inline should fit the bill. Then it would always make it
> inline to the immediately enclosing namespace.
Sounds reasonable.
>>>>>> For operator functions, set GCC_CP_FLAG_SPECIAL_FUNCTION in
>>>>>>> + SYM_KIND, in addition to any other applicable flags, and pass as
>>>>>>> + NAME a string starting with the two-character mangling for operator
>>>>>>> + name
>>>>>
>>>>>> Perhaps the compiler side should handle this transparently?
>>>>>
>>>>> Sorry, I don't understand what you're suggesting. Can you please
>>>>> elaborate?
>>>
>>>> I mean have the compiler recognize that the name is magic and infer
>>>> that it's a special function.
>>>
>>> I'd rather not have accidental namespace collisions: there are several
>>> layers with different conventions at play, so I decided to mark such
>>> things explicitly so as to be able to catch misuses. Consider that we
>>> have GCC's internal identifier representation, mangled identifier
>>> representation, names exported in debug information, and GDB's internal
>>> representation. When we get a special name, we want to be sure there
>>> was not a failure to convert between one's internal representation and
>>> libcc1's conventions. That's what motivated me to mark them explicitly.
>
>> It sounds like you're saying that you want the user to provide the
>> same information two different ways in order to make sure they're
>> getting it right. That seems kind of cumbersome.
>
> I can't see it that way. The information is not provided in two
> different ways. Consider, for example, the string used to denote
> constructors. It's perfectly legitimate to name a member function "C4",
> but we also use this representation to name constructors, so we need at
> least an additional bit to tell which space the name belongs to. We
> could make the encoding part of the string ('_' prefixes, mangling,
> whatever), but I thought it was better to leave the names unmangled, and
> use a separate bit flag to "escape" the names into the special functions
> space.
>
> OF course we could have gone with other conventions. One I considered
> was looking for blanks in the names: they can't appear in regular names,
> and we could mandate them to be present in special function names. In
> the end, I went for the separate bit.
>
>
>>> Adopting the name mangling conventions, rather than some enumeration or
>>> so, is justified by the need for some arbitrary convention, and reusing
>>> an existing one (that is NOT present in debug information names)
>
>> Isn't it present in DW_AT_linkage_name?
>
> It's part of the mangled name, yes, but you'd have to look for it. It's
> not something you'd get to by accident or mistake.
All right.
Jason
