Historically Clang didn't have representation of __private and therefore it has never been printed in types. It appeared to be the same as no address space and appeared to be confusing to the users. Also it was unnecessarily exposing the implementation details of Clang.
We have added a representation of it in AST https://reviews.llvm.org/D35082 but it hasn't been added to the type printing yet.
Current patch adds printing of __private in type printer. The main motivation for this are:
- Avoid situations where __private addr space is missing in the type of diagnostics even if it was provided in the source code.
- Improve frontend debugging support because we will now be able to differentiate between __private and absence of addr space in AST dumps.
There is one potential issue that some diagnostics will become more verbose with extra __private addr spaces being printed that were deduced implicitly. This aligns however with the rest of behaviour i.e. deduced __generic addr space is currently printed in AST dump and diagnostics. It is also reasonable for deduced addr spaces to appear in type printing because it can be explained by the language rules. However, absence of __private from type printing has been an implementation detail of Clang that never was intuitive to the users.
Minor. An error message like this looks a bit confusing to me. User might wonder whether parameters are incompatible because of address space or because of access qualifiers. Should it print passing '__private img1d_wo' (aka '__private __write_only image1d_t') to parameter of incompatible type '__private __read_only image1d_t'? In this case it is clear that there is a mismatch in access qualifiers.