[cfe-dev] @encode() discrepancy between C++11 and earlier

[Richard Smith via cfe-dev]

I think some of the other recent TypePrinter changes might also risk
changing the @encode output. Generally it seems unwise for @encode to be
using the type pretty-printer if it wants to be ABI-stable; I don't think
it's reasonable to expect any guarantees as to the stability of
pretty-printed type names. I think USR generation suffers from similar
problems; it too uses the type pretty-printer to generate
supposedly-ABI-stable keys in at least some cases.

On Thu, 12 Nov 2020 at 13:44, Duncan P. N. Exon Smith via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Hi Nico,
>
> Thanks for reaching out. Michael Spencer is probably the best contact for
> this kind of question these days; I’ve cc’ed him.
>
> Duncan
>
> On 2020-11-12, at 09:04, Nico Weber <thakis at chromium.org> wrote:
>
> Hi,
>
> http://reviews.llvm.org/D76801 changed clang/lib/AST/TypePrinter.cpp to
> not print a space between consecutive '>'s in templates if targeting C++11
> or later.
>
> I noticed recently that this affects Objective-C's @encode too, which
> means it has different results based on language standard, making it
> impossible to build part of a program with C++98 and another part with
> C++11 (...if both parts need @encode if some common type to agree). It also
> means @encode for types changed with that patch, which is an ABI break of
> sorts.
>
> However, the change landed in March, so maybe it's already deployed in new
> Xcodes.
>
> Should we make @encode opt out of this pretty printing change to restore
> the old behavior? (Several other places also broke due to that change and
> were changed to opt out -- debug info, for example).
>
> I found this while writing tests for an unrelated change [1] and I don't
> know of any projects adversely affected by this.
>
> Nico
>
>
> 1: See "FIXME" in https://reviews.llvm.org/D90622#change-Aht3gYP3AIRe
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20201112/511daa00/attachment.html>