[cfe-dev] How to deal with mangled names matching with extern "C" ones?

[Richard Smith]

On Tue, Jul 7, 2015 at 8:18 AM, Reid Kleckner <rnk at google.com> wrote:

> I think we should just fix the assert by erroring out from CodeGen when it
> detects that two Decls have the same mangled name. This might be tricky
> because we usually assume that decls have a unique mangled name.
>

That is both reasonable and what we already attempt to do, but we don't do
so particularly thoroughly or consistently. For instance:

  int _Z1fv;
  void f() {} // gives an error "definition with same mangled name as
another definition"

but:

  void f() {}
  int _Z1fv; // no error, variable silently replaces function


> If people want to compile C++ transpiled to C, I don't see why clang
> should forbid that. The Itanium ABI restricts itself to valid C identifiers
> to support this exact use case.
>

I agree. While it may be reasonable to warn on reserved identifiers outside
system headers, we should still accept them when they don't conflict with
some other meaning we've assigned to them. CodeGen needs to be able to deal
with name conflicts, and should avoid crashing when they occur. And this
problem is not limited to C++ name mangling; we get a conflict here too:

  int n = 1;
  int m __asm__("n") = 2;


> On Tue, Jul 7, 2015 at 7:44 AM, Andrey Bokhanko <andreybokhanko at gmail.com>
> wrote:
>
>> Hmmm, maybe we should just check that identifiers don't start with
>> _[A-Z] and print an error if they are?
>>
>> Richard [Smith], what do you think?
>>
>> Yours,
>> Andrey
>>
>>
>> On Tue, Jul 7, 2015 at 2:39 PM, Renato Golin <renato.golin at linaro.org>
>> wrote:
>> > On 7 July 2015 at 12:20, Stephan Bergmann <sbergman at redhat.com> wrote:
>> >> [lex.name]/3.1: "Each identifier that contains a double underscore __
>> or
>> >> begins with an underscore followed by an
>> >> uppercase letter is reserved to the implementation for any use."
>> >
>> > Right, I always forget the _[A-Z] case. I guess how we deal with this
>> > is up to interpretation.
>> >
>> > cheers,
>> > --renato
>> > _______________________________________________
>> > cfe-dev mailing list
>> > cfe-dev at cs.uiuc.edu
>> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150707/8d60fbf7/attachment.html>