Re: Bug in QualTypeNames.cpp and adding an option to prepend "::" to fully qualified names.

[Jean-Baptiste Lespiau via cfe-commits]

lifiedName has a bug,
>>> and people should move to use qual_type.getAsString(Policy) instead, using
>>> "FullyQualifiedName" and "GlobalScopeQualifiedName". We can for example
>>> provide :
>>>
>>
>> It'd still fall to one of us Googlers to clean this all up inside Google
>> - since we build with -Werror, it's not like folks'll just get soft
>> encouragement to migrate away from the API, either the warning will be on
>> and their build will be broken (in which case we'll probably pick it up
>> when we integrate changes from upstream & have to fix it to complete that
>> integration) or no signal, and it'll break when the function is finally
>> removed.
>>
>>
>>> std::string GetFullyQualifiedCanonicalType(QualType qual_type, const
>>> ASTContext &ast,)
>>>   clang::PrintingPolicy print_policy(ast.GetASTContext().getLangOpts());
>>>   print_policy.FullyQualifiedName = 1;
>>>   print_policy.SuppressScope = 0;
>>>   print_policy.PrintCanonicalTypes = 1;
>>>   print_policy.GlobalScopeQualifiedName = 1;
>>>   QualType canonical_type = qual_type.getCanonicalType();
>>>   return canonical_type.getAsString(print_policy);
>>> }
>>> (c) Then, people can upgrade asynchronously, maybe someone will be
>>> unhappy with this behavior and will suggest something else, etc.
>>>
>>> If we just blindly delete it, it means for example that we have to fix
>>> all usages in Google to be able to upgrade Clang.  It may be the approach
>>> that is decided we should follow, but I just wanted to make it clear that I
>>> will not be able to do that job^^ While, having an incremental fix in
>>> Clang, and then fix Clif is doable as it does not imply to fix all calls in
>>> one go.
>>>
>>> I just wanted to develop these points.
>>>
>>
>> Sure enough - appreciate the awareness of the cost to external clients,
>> to be sure.
>>
>> - Dave
>>
>>
>>>
>>> Thanks!
>>>
>>> On Tue, May 12, 2020 at 7:59 PM David Blaikie 
>>> wrote:
>>>
>>>> +Mr. Smith for visibility.
>>>>
>>>> I'm /guessing/ the right path might be to change the implementation of
>>>> getFullyQualifiedName to use the type printing/pretty printer approach with
>>>> the extra feature you're suggesting. That way all users get the desired
>>>> behavior
>>>>
>>>> +Sam McCall   who (if I understand correctly)
>>>> has a lot to do with the Clang Tooling work - looks like Google's got a
>>>> bunch of uses of this function (getFullyQualifiedName) internally in clang
>>>> tools (I wonder why that's the case when there are still zero external
>>>> callers - is that OK? Or are external users doing something different
>>>> (better? worse?) to answer this question - or the tooling uses in LLVM
>>>> proper just don't have the same needs?). So probably best not to leave a
>>>> buggy implementation lying around - either deleting it, or fixing it.
>>>>
>>>> On Mon, May 11, 2020 at 11:28 PM Jean-Baptiste Lespiau via cfe-commits <
>>>> cfe-commits@lists.llvm.org> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> *Context and history:*
>>>>>
>>>>> I have found a bug in CLIF <https://github.com/google/clif>, which
>>>>> does not correctly fully qualify templated names when they are nested, 
>>>>> e.g.
>>>>>
>>>>> ::tensorfn::Nested< ::std::variant >
>>>>>
>>>>> should have been:
>>>>>
>>>>> ::tensorfn::Nested<
>>>>> ::std::variant<::tensorflow::Tensor,::tensorfn::DeviceTensor> >
>>>>>
>>>>> I tracked it down to
>>>>> https://github.com/google/clif/blob/master/clif/backend/matcher.cc#L172
>>>>> which calls
>>>>>
>>>>> https://github.com/llvm-mirror/clang/blob/master/lib/AST/QualTypeNames.cpp
>>>>> and the error is exactly at the line, but I could not really
>>>>> understand why.
>>>>>
>>>>> https://github.com/llvm-mirror/clang/blob/master/lib/AST/QualTypeNames.cpp#L457
>>>>>
>>>>> Historically, it has been added by the developers of CLIF
>>>>> (including Sterling Augustine)
>>>>>
>>>>>

Re: Bug in QualTypeNames.cpp and adding an option to prepend "::" to fully qualified names.

[Jean-Baptiste Lespiau via cfe-commits]

t;>
> >>>>>
> >>>>> std::string GetFullyQualifiedCanonicalType(QualType qual_type, const
> ASTContext &ast,)
> >>>>>   clang::PrintingPolicy
> print_policy(ast.GetASTContext().getLangOpts());
> >>>>>   print_policy.FullyQualifiedName = 1;
> >>>>>   print_policy.SuppressScope = 0;
> >>>>>   print_policy.PrintCanonicalTypes = 1;
> >>>>>   print_policy.GlobalScopeQualifiedName = 1;
> >>>>>   QualType canonical_type = qual_type.getCanonicalType();
> >>>>>   return canonical_type.getAsString(print_policy);
> >>>>> }
> >>>>> (c) Then, people can upgrade asynchronously, maybe someone will be
> unhappy with this behavior and will suggest something else, etc.
> >>>>>
> >>>>> If we just blindly delete it, it means for example that we have to
> fix all usages in Google to be able to upgrade Clang.  It may be the
> approach that is decided we should follow, but I just wanted to make it
> clear that I will not be able to do that job^^ While, having an incremental
> fix in Clang, and then fix Clif is doable as it does not imply to fix all
> calls in one go.
> >>>>>
> >>>>> I just wanted to develop these points.
> >>>>
> >>>>
> >>>> Sure enough - appreciate the awareness of the cost to external
> clients, to be sure.
> >>>>
> >>>> - Dave
> >>>>
> >>>>>
> >>>>>
> >>>>> Thanks!
> >>>>>
> >>>>> On Tue, May 12, 2020 at 7:59 PM David Blaikie 
> wrote:
> >>>>>>
> >>>>>> +Mr. Smith for visibility.
> >>>>>>
> >>>>>> I'm /guessing/ the right path might be to change the implementation
> of getFullyQualifiedName to use the type printing/pretty printer approach
> with the extra feature you're suggesting. That way all users get the
> desired behavior
> >>>>>>
> >>>>>> +Sam McCall  who (if I understand correctly) has a lot to do with
> the Clang Tooling work - looks like Google's got a bunch of uses of this
> function (getFullyQualifiedName) internally in clang tools (I wonder why
> that's the case when there are still zero external callers - is that OK? Or
> are external users doing something different (better? worse?) to answer
> this question - or the tooling uses in LLVM proper just don't have the same
> needs?). So probably best not to leave a buggy implementation lying around
> - either deleting it, or fixing it.
> >>>>>>
> >>>>>> On Mon, May 11, 2020 at 11:28 PM Jean-Baptiste Lespiau via
> cfe-commits  wrote:
> >>>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> Context and history:
> >>>>>>>
> >>>>>>> I have found a bug in CLIF, which does not correctly fully qualify
> templated names when they are nested, e.g.
> >>>>>>>
> >>>>>>> ::tensorfn::Nested< ::std::variant >
> >>>>>>>
> >>>>>>> should have been:
> >>>>>>>
> >>>>>>> ::tensorfn::Nested<
> ::std::variant<::tensorflow::Tensor,::tensorfn::DeviceTensor> >
> >>>>>>>
> >>>>>>> I tracked it down to
> >>>>>>>
> https://github.com/google/clif/blob/master/clif/backend/matcher.cc#L172
> >>>>>>> which calls
> >>>>>>>
> https://github.com/llvm-mirror/clang/blob/master/lib/AST/QualTypeNames.cpp
> >>>>>>> and the error is exactly at the line, but I could not really
> understand why.
> >>>>>>>
> https://github.com/llvm-mirror/clang/blob/master/lib/AST/QualTypeNames.cpp#L457
> >>>>>>>
> >>>>>>> Historically, it has been added by the developers of CLIF
> (including Sterling Augustine)
> >>>>>>>
> https://github.com/llvm/llvm-project/commit/0dd191a5c4bf27cc8a2b6033436b00f0cbdc4ce7
> .
> >>>>>>> They explained to me, that they pushed this to Clang hoping it
> would be used by other tools and maintained by the community, but that it
> kind of failed at that, and it (i.e. QualTypeName.pp) is not much used, and
> not much maintained.
> >>>>>>>
> >>>>>>> I was not able to understand this file to provide a fix. On the
> other side, it was easy to understand TypePrinter.cpp and
> PrettyPrinter.cpp, so I tried extending it to fit my need.
> >>>>>>>
> >>>>>>> Suggestion
> >>>>>>>
> >>>>>>>  As I wanted fully qualified types (it's usually more convenient
> for tools generating code), to prevent some complex errors), I added ~10
> lines that add an option to prepend "::" to qualified types (see the patch).
> >>>>>>>
> >>>>>>> In practice, it is still a different display at what
> QualTypeNames.cpp was doing, as, for example, it displays
> >>>>>>>
> >>>>>>> ::tensorfn::Nested<::std::__u::variant ::tensorfn::DeviceTensor>>
> >>>>>>>
> >>>>>>> but I was able to solve my issues. More generally, it is more
> verbose, as it displays the exact underlying type, including default
> parameter types in template arguments. So it's verbose, but it's correct
> (what is best?^^).
> >>>>>>>
> >>>>>>> I am contacting you, so we can discuss:
> >>>>>>>
> >>>>>>> - Whether QualTypeNames.cpp is something useful for the Clang
> project, whether you think we should fix the bug I have found (but I
> cannot, as I do not understand it), or whether we should deprecate it, or
> modify the current printing mechanism (TypePrinter.cpp and
> PrettyPrinter.cpp) to add more options to tune the display in ways people
> may want to.
> >>>>>>> - Whether adding the CL I have attached is positive, and if yes,
> what should be done in addition to that (does it need tests? Are there more
> types that we may want to prepend "::" to its fully qualified name?).
> >>>>>>>
> >>>>>>> Thanks!
> >>>>>>>
> >>>>>>> ___
> >>>>>>> cfe-commits mailing list
> >>>>>>> cfe-commits@lists.llvm.org
> >>>>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Bug in QualTypeNames.cpp and adding an option to prepend "::" to fully qualified names.

[Jean-Baptiste Lespiau via cfe-commits]

Hi,

*Context and history:*

I have found a bug in CLIF , which does not
correctly fully qualify templated names when they are nested, e.g.

::tensorfn::Nested< ::std::variant >

should have been:

::tensorfn::Nested<
::std::variant<::tensorflow::Tensor,::tensorfn::DeviceTensor> >

I tracked it down to
https://github.com/google/clif/blob/master/clif/backend/matcher.cc#L172
which calls
https://github.com/llvm-mirror/clang/blob/master/lib/AST/QualTypeNames.cpp
and the error is exactly at the line, but I could not really understand why.
https://github.com/llvm-mirror/clang/blob/master/lib/AST/QualTypeNames.cpp#L457

Historically, it has been added by the developers of CLIF
(including Sterling Augustine)
https://github.com/llvm/llvm-project/commit/0dd191a5c4bf27cc8a2b6033436b00f0cbdc4ce7
.
They explained to me, that they pushed this to Clang hoping it would be
used by other tools and maintained by the community, but that it kind of
failed at that, and it (i.e. QualTypeName.pp) is not much used, and not
much maintained.

I was not able to understand this file to provide a fix. On the other side,
it was easy to understand TypePrinter.cpp and PrettyPrinter.cpp, so I tried
extending it to fit my need.

*Suggestion*

 As I wanted fully qualified types (it's usually more convenient for tools
generating code), to prevent some complex errors), I added ~10 lines that
add an option to prepend "::" to qualified types (see the patch).

In practice, it is still a different display at what QualTypeNames.cpp was
doing, as, for example, it displays

::tensorfn::Nested<::std*::__u*::variant>

but I was able to solve my issues. More generally, it is more verbose, as
it displays the exact underlying type, including default parameter types in
template arguments. So it's verbose, but it's correct (what is best?^^).

I am contacting you, so we can discuss:

- Whether QualTypeNames.cpp
 is
something useful for the Clang project, whether you think we should fix the
bug I have found (but I cannot, as I do not understand it), or whether we
should deprecate it, or modify the current printing mechanism
(TypePrinter.cpp and PrettyPrinter.cpp) to add more options to tune the
display in ways people may want to.
- Whether adding the CL I have attached is positive, and if yes, what
should be done in addition to that (does it need tests? Are there more
types that we may want to prepend "::" to its fully qualified name?).

Thanks!
commit 667bb3761fde65671db156cedd3fa6db37d13ee1
Author: Jean-Baptiste Lespiau 
Date:   Tue May 12 01:07:59 2020 +0200

Add an option to fully qualify classes and structs.

diff --git a/clang/include/clang/AST/PrettyPrinter.h b/clang/include/clang/AST/PrettyPrinter.h
index 616647f4443..5ea704d9465 100644
--- a/clang/include/clang/AST/PrettyPrinter.h
+++ b/clang/include/clang/AST/PrettyPrinter.h
@@ -63,7 +63,8 @@ struct PrintingPolicy {
 MSWChar(LO.MicrosoftExt && !LO.WChar), IncludeNewlines(true),
 MSVCFormatting(false), ConstantsAsWritten(false),
 SuppressImplicitBase(false), FullyQualifiedName(false),
-PrintCanonicalTypes(false), PrintInjectedClassNameWithArguments(true) {}
+GlobalScopeQualifiedName(false), PrintCanonicalTypes(false),
+PrintInjectedClassNameWithArguments(true) {}
 
   /// Adjust this printing policy for cases where it's known that we're
   /// printing C++ code (for instance, if AST dumping reaches a C++-only
@@ -241,6 +242,13 @@ struct PrintingPolicy {
   /// This is the opposite of SuppressScope and thus overrules it.
   unsigned FullyQualifiedName : 1;
 
+  // When true, class and struct types (to be expanded if needed) will be
+  // prepended with "::"
+  // Note it also requires `FullyQualifiedName` to also be set to true, as it
+  // does not make sense to prepend "::" to a non fully-qualified name.
+  // This targets generated code.
+  unsigned GlobalScopeQualifiedName : 1;
+
   /// Whether to print types as written or canonically.
   unsigned PrintCanonicalTypes : 1;
 
diff --git a/clang/lib/AST/TypePrinter.cpp b/clang/lib/AST/TypePrinter.cpp
index 6f6932e6521..29f347a8730 100644
--- a/clang/lib/AST/TypePrinter.cpp
+++ b/clang/lib/AST/TypePrinter.cpp
@@ -19,6 +19,7 @@
 #include "clang/AST/DeclTemplate.h"
 #include "clang/AST/Expr.h"
 #include "clang/AST/NestedNameSpecifier.h"
+#include "clang/AST/PrettyPrinter.h"
 #include "clang/AST/TemplateBase.h"
 #include "clang/AST/TemplateName.h"
 #include "clang/AST/Type.h"
@@ -40,6 +41,7 @@
 #include "llvm/Support/SaveAndRestore.h"
 #include "llvm/Support/raw_ostream.h"
 #include 
+#include 
 #include 
 
 using namespace clang;
@@ -320,6 +322,10 @@ void TypePrinter::printBefore(const Type *T,Qualifiers Quals, raw_ostream &OS) {
   HasEmptyPlaceHolder = false;
   }
 
+  if (Policy.FullyQualifiedName && Policy.GlobalScopeQualifiedName &&
+  (T->isStructureOrClassType())) {
+OS << "::"

Re: Bug in QualTypeNames.cpp and adding an option to prepend "::" to fully qualified names.

[Jean-Baptiste Lespiau via cfe-commits]

Hi,

thanks for your answer.

Just a few remarks:

1. I imagine that we cannot know if people are using getFullyQualifiedName.
In particular, people could have developed their own internal tools, thus
we cannot be aware of all callers. I do not know Clang's policy, but can we
delete or completely change a function without deprecating it first? I was
imagining that the process was to deprecate it, document the case where it
can be incorrect, and that in a next release it gets deleted/replaced (or
someone steps up to fix it).
2. As example of different behaviors:
(a) the qual_type.getAsString() will print implementation namespace details
(e.g. ::std*::__u*::variant instead of std::variant).
(b) It will also display default template arguments, e.g.
template 
class MyClass
is printed as MyClass (I think) in getFullyQualifiedName, while
getAsString() will use MyClass.
(c) the example of the nested template argument above.

At the end,what matters is that getAsString() is semantically always
correct, even if it can be overly verbose. I tried to
fix getFullyQualifiedName, but I do not understand its code.

3. When the goal we want to reach has been decided, there is also the
question on how to transition from the current state to the next state, and
who can help with that. To be way clearer, I won't be able to fix all of
Google internal usage of this function (I am not at all working on Clang,
Clif, or any tools, I just hit the bug and decided to look into it, and it
happened that I found a fix). Thus, if we can do the changes using
iterative steps, such as
(a) add the new "::" prefix configuration,
(b) Deprecate/document the fact that getFullyQualifiedName has a bug, and
people should move to use qual_type.getAsString(Policy) instead, using
"FullyQualifiedName" and "GlobalScopeQualifiedName". We can for example
provide :

std::string GetFullyQualifiedCanonicalType(QualType qual_type, const
ASTContext &ast,)
  clang::PrintingPolicy print_policy(ast.GetASTContext().getLangOpts());
  print_policy.FullyQualifiedName = 1;
  print_policy.SuppressScope = 0;
  print_policy.PrintCanonicalTypes = 1;
  print_policy.GlobalScopeQualifiedName = 1;
  QualType canonical_type = qual_type.getCanonicalType();
  return canonical_type.getAsString(print_policy);
}
(c) Then, people can upgrade asynchronously, maybe someone will be unhappy
with this behavior and will suggest something else, etc.

If we just blindly delete it, it means for example that we have to fix all
usages in Google to be able to upgrade Clang.  It may be the approach that
is decided we should follow, but I just wanted to make it clear that I will
not be able to do that job^^ While, having an incremental fix in Clang, and
then fix Clif is doable as it does not imply to fix all calls in one go.

I just wanted to develop these points.

Thanks!

On Tue, May 12, 2020 at 7:59 PM David Blaikie  wrote:

> +Mr. Smith for visibility.
>
> I'm /guessing/ the right path might be to change the implementation of
> getFullyQualifiedName to use the type printing/pretty printer approach with
> the extra feature you're suggesting. That way all users get the desired
> behavior
>
> +Sam McCall   who (if I understand correctly) has a
> lot to do with the Clang Tooling work - looks like Google's got a bunch of
> uses of this function (getFullyQualifiedName) internally in clang tools (I
> wonder why that's the case when there are still zero external callers - is
> that OK? Or are external users doing something different (better? worse?)
> to answer this question - or the tooling uses in LLVM proper just don't
> have the same needs?). So probably best not to leave a buggy implementation
> lying around - either deleting it, or fixing it.
>
> On Mon, May 11, 2020 at 11:28 PM Jean-Baptiste Lespiau via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Hi,
>>
>> *Context and history:*
>>
>> I have found a bug in CLIF <https://github.com/google/clif>, which does
>> not correctly fully qualify templated names when they are nested, e.g.
>>
>> ::tensorfn::Nested< ::std::variant >
>>
>> should have been:
>>
>> ::tensorfn::Nested<
>> ::std::variant<::tensorflow::Tensor,::tensorfn::DeviceTensor> >
>>
>> I tracked it down to
>> https://github.com/google/clif/blob/master/clif/backend/matcher.cc#L172
>> which calls
>> https://github.com/llvm-mirror/clang/blob/master/lib/AST/QualTypeNames.cpp
>> and the error is exactly at the line, but I could not really understand
>> why.
>>
>> https://github.com/llvm-mirror/clang/blob/master/lib/AST/QualTypeNames.cpp#L457
>>
>> Historically, it has been added by the developers of CLIF
>> (including Sterling Augustine)
>>
>> https://github.com/llvm/l

Re: Bug in QualTypeNames.cpp and adding an option to prepend "::" to fully qualified names.

[Jean-Baptiste Lespiau via cfe-commits]

t blindly delete it, it means for example that we have to fix
>> all usages in Google to be able to upgrade Clang.  It may be the approach
>> that is decided we should follow, but I just wanted to make it clear that I
>> will not be able to do that job^^ While, having an incremental fix in
>> Clang, and then fix Clif is doable as it does not imply to fix all calls in
>> one go.
>>
>> I just wanted to develop these points.
>>
>
> Sure enough - appreciate the awareness of the cost to external clients, to
> be sure.
>
> - Dave
>
>
>>
>> Thanks!
>>
>> On Tue, May 12, 2020 at 7:59 PM David Blaikie  wrote:
>>
>>> +Mr. Smith for visibility.
>>>
>>> I'm /guessing/ the right path might be to change the implementation of
>>> getFullyQualifiedName to use the type printing/pretty printer approach with
>>> the extra feature you're suggesting. That way all users get the desired
>>> behavior
>>>
>>> +Sam McCall   who (if I understand correctly) has
>>> a lot to do with the Clang Tooling work - looks like Google's got a bunch
>>> of uses of this function (getFullyQualifiedName) internally in clang tools
>>> (I wonder why that's the case when there are still zero external callers -
>>> is that OK? Or are external users doing something different (better?
>>> worse?) to answer this question - or the tooling uses in LLVM proper just
>>> don't have the same needs?). So probably best not to leave a buggy
>>> implementation lying around - either deleting it, or fixing it.
>>>
>>> On Mon, May 11, 2020 at 11:28 PM Jean-Baptiste Lespiau via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
>>>> Hi,
>>>>
>>>> *Context and history:*
>>>>
>>>> I have found a bug in CLIF <https://github.com/google/clif>, which
>>>> does not correctly fully qualify templated names when they are nested, e.g.
>>>>
>>>> ::tensorfn::Nested< ::std::variant >
>>>>
>>>> should have been:
>>>>
>>>> ::tensorfn::Nested<
>>>> ::std::variant<::tensorflow::Tensor,::tensorfn::DeviceTensor> >
>>>>
>>>> I tracked it down to
>>>> https://github.com/google/clif/blob/master/clif/backend/matcher.cc#L172
>>>> which calls
>>>>
>>>> https://github.com/llvm-mirror/clang/blob/master/lib/AST/QualTypeNames.cpp
>>>> and the error is exactly at the line, but I could not really understand
>>>> why.
>>>>
>>>> https://github.com/llvm-mirror/clang/blob/master/lib/AST/QualTypeNames.cpp#L457
>>>>
>>>> Historically, it has been added by the developers of CLIF
>>>> (including Sterling Augustine)
>>>>
>>>> https://github.com/llvm/llvm-project/commit/0dd191a5c4bf27cc8a2b6033436b00f0cbdc4ce7
>>>> .
>>>> They explained to me, that they pushed this to Clang hoping it would be
>>>> used by other tools and maintained by the community, but that it kind of
>>>> failed at that, and it (i.e. QualTypeName.pp) is not much used, and not
>>>> much maintained.
>>>>
>>>> I was not able to understand this file to provide a fix. On the other
>>>> side, it was easy to understand TypePrinter.cpp and PrettyPrinter.cpp, so I
>>>> tried extending it to fit my need.
>>>>
>>>> *Suggestion*
>>>>
>>>>  As I wanted fully qualified types (it's usually more convenient for
>>>> tools generating code), to prevent some complex errors), I added ~10 lines
>>>> that add an option to prepend "::" to qualified types (see the patch).
>>>>
>>>> In practice, it is still a different display at what QualTypeNames.cpp
>>>> was doing, as, for example, it displays
>>>>
>>>> ::tensorfn::Nested<::std*::__u*::variant>>> ::tensorfn::DeviceTensor>>
>>>>
>>>> but I was able to solve my issues. More generally, it is more verbose,
>>>> as it displays the exact underlying type, including default parameter types
>>>> in template arguments. So it's verbose, but it's correct (what is best?^^).
>>>>
>>>> I am contacting you, so we can discuss:
>>>>
>>>> - Whether QualTypeNames.cpp
>>>> <https://github.com/llvm-mirror/clang/blob/master/lib/AST/QualTypeNames.cpp>
>>>>  is
>>>> something useful for the Clang project, whether you think we should fix the
>>>> bug I have found (but I cannot, as I do not understand it), or whether we
>>>> should deprecate it, or modify the current printing mechanism
>>>> (TypePrinter.cpp and PrettyPrinter.cpp) to add more options to tune the
>>>> display in ways people may want to.
>>>> - Whether adding the CL I have attached is positive, and if yes, what
>>>> should be done in addition to that (does it need tests? Are there more
>>>> types that we may want to prepend "::" to its fully qualified name?).
>>>>
>>>> Thanks!
>>>>
>>>> ___
>>>> cfe-commits mailing list
>>>> cfe-commits@lists.llvm.org
>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>>>
>>>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits