[PATCH] D112374: [clang] Implement ElaboratedType sugaring for types written bare

Fri Aug 12 03:24:48 PDT 2022

mizvekov added a comment.

In D112374#3718417 <https://reviews.llvm.org/D112374#3718417>, @ilya-biryukov wrote:

> We don't match GCC in other cases. GCC seems to always print the type name without qualifiers, clang used to always print with qualifiers, but will now print what was typed in the code, see https://gcc.godbolt.org/z/jznncGboM

Well, Clang always tried printing them as typed in the code, except for this bug that we fixed here.

It would fail to represent a name written without both qualifiers and elaboration. If it had either or both, it would print the name as-written.
Example: https://gcc.godbolt.org/z/3xv4xxYf1

So, consider that relying on `__PRETTY_FUNCTION__` output was pretty unreliable from the get go, as you already had different results across compilers.

Also, consider these other points:

- This patch had a lot of test churn, but no test churn on `__PRETTY_FUNCTION__` tests, so I think this means that this was pretty much untested on Clang's part.
- The implementation relies on reconstructing the function signature as-written from the AST. So any improvement in that area would cause changes, or extra complexity to keep the old limitations around behind switches.
- There seems to be no attempt to enforce the stability of this result at the architectural level in Clang. It relies directly on the type printer, which is used all around in many different scenarios, and you can see that folks here just make changes to the type printer for cosmetic reasons, with little vetting and no concern for stability.

Otherwise, the type printer is customizable with Policies, so you could think of adding a new one to customize this behavior. But even then, I think the old Clang behavior was too weird to make an option for it.
What would we even call such a policy, something like `InventFullNameQualifierIfNeitherQualifiedOrElaborated`?

We could make a separate type printer system for such a macro, stripping the function signature of any decoration and using a stable policy, and create all the test cases for it so that we don't regress accidentally.
We could leave the current macro as is, printing the signature as written, and add this new one behind a new macro, so that the user gets to choose between `__PRETTY_FUNCTION__` and `__NAKED_FUNCTION__`? 🤔

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D112374/new/

https://reviews.llvm.org/D112374